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INTRODUCTION 


This  document  is  a  Phase  I  Require¬ 
ments  Definition  that  provides  necessary  archi¬ 
tectural  guidance  to  restructure  all  Navy  com¬ 
mand  and  control,  communications  and  com¬ 
puters,  and  intelligence  (C4I)  systems  under  the 
Copernicus  Architecture.  All  existing  Navy 
C4I-related  plans  and  programs  undo:  the  spon¬ 
sorship  of  OP-094  shall  be  subordinated  lu  tills  ' 
document  and  the  architecture  described  in  it 

Specific  programmatic  and  implemen¬ 
tation  requirements  are  detailed  in  Chapters  9 
and  10  of  this  document  which  provides 
direction  to  the  Commander,  Space  and  Naval 
Warfare  Systems  Command  (COM- 
SPAWARS  YSCOM)  to  implement  it 

This  document  is  the  result  of  an  18- 
month  architectural  effort  sponsored  by  OP-094 
to  develop  a  post-Cold  War  C4I  architecture  for 
the  Navy.  The  requirements  definition  stems 
from  multiple  efforts  including  those  of  the 
Copernicus  Project  Team  and  three  specially 
convened  working  groups:  one  each  for 
technology,  communications,  and  investment 
strategy.  Key  findings  and  recommendations 
from  the  reports  of  the  working  groups,  which 
had  representation  from  OPNAV,  COM- 
SPAWARS  YSCOM,  the  Fleet  Commanders- 
in-Chief  (FLTCINCs),  and  various  claimancies 
and  industry,  are  contained  in  Appendices  A,  B, 
and  C.  Figure  1-1  shows  the  process. 


The  undertaking  of  an  entirely  new  ar¬ 
chitecture  for  Navy  C4I  is  an  enormous  task  that 
will  require  considerable  effort  over  several 
years  and  the  continued  involvement  of  not  only 
OP-094  and  COMSPAWARSYSCOM  person¬ 
nel,  but  also  of  the  customer,  the  FLTCENC. 
This  process  is  planned  to  occur  in  phases,  and 
wfflremployTherprinciples  of  the  Total  Quality 
Leadership  program,  especially  Process  Action 
Teams,  as  well  as  standing  working  groups. 
Most  importantly  the  process  reflects  OP-094’s 
commitment  that  the  Copernicus  Architecture 
be  an  unprecedented  model  for  OPNAV, 
COMSPAWARSYSCOM,  claimancy,  and 
FLTQNC  cooperation. 

PHASE  II  EFFORTS 

Phase  II  will  consist  of  three  main  thrusts 
(see  fig.  1-2): 

•  The  establishment  on  the  OP-094 staff  of  a  Space 
and  Electronic  Warfare  (SEW)  Architect  del¬ 
egated  broad  architectural,  managerial,  and  op¬ 
erational  authority  over  the  development  of  the 
SEW  systems  including  die  Copernicus  Archi¬ 
tecture; 

•  The  establishment  on  the  Space  and  Naval 
Warfare  Systems  Command  (COM¬ 
SPAWARSYSCOM)  staff  of  a  SEW  engineer, 
delegated  systems  integration  and  engineering 
oversight  of  the  SEW  systems,  including  the 
Copernicus  Architecture;  and 
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•  The  establishment  on  the  OP-094  staff  of  a  SEW 
programmer,  delegated  responsibility  far  pro¬ 
grammatic  integration  of  SEW  systems,  includ¬ 
ing  the  Copernicus  Architecture. 

The  SEW  architect  will  be  established  as 
a  staff  element  independent  of  existing  division 
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directors.  The  architect's  responsibilities  will 
include  architectural  and  operational  oversight 
of  all  OP-094- sponsored  programs,  existing  and 
future,  to  ensure  full  compliance  with  Copernicus 
standards  and  applicability  within  the 
architecture. 
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During  Phase  II  efforts,  the  architect  will 
focus  on  two  broad  areas,  the  establishment  of 
working  groups  composed  of  fleet,  claimancy, 
and  industry  personnel  to  produce  individual 
operational  requirements  (OR)  and  concepts  of 
operations  (CONOP)  for  the  four  pillars,  and  to 
ygpunH  the  level  of  detail  in  die  architecture 
across  Navy  Department  disciplines  (e.g..  Sub¬ 
marine  Forces,  Marine  Air  Ground  Task  Forces, 
Special  Operating  Forces)  and,  if  directed,  up 
and  across  echelons  into  a  joint  model,  — -  •  ■ 

The  SEW  engineer  will  be  established  in 
COMSPAWARSYSCOM.  The  engineer's  re¬ 
sponsibilities  will  include  Copernicus  systems 
engineering,  the  development  of  engineering 
models,  “best  of  breed”  building  block  selec¬ 
tion,  rapid  prototyping  efforts.  Common  Oper¬ 
ating  Environment  (COE)  definition,  and  gen¬ 
eral  technical  support  far  the  SEW  architect 

During  Phase  n  efforts,  the  engineer  will 
focus  on  four  tasks: 

•  The  development  of  a  functional  description 
document  for  each  of  the  pillars; 

•  The  development  of  an  end-to-end,  integrated, 
engineering  model  of  the  pillars; 

•  From  that  model,  a  “best  of  breed"  building 
block  selection  recommendation  to  the  Archi¬ 
tect  and 

•  The  expansion  of  existing  fleet  engineering  and 
monitoring  efforts  Over-the-horizon  targeting 
(QIH-T)  into  SEW  field  engineering  support 


The  SEW  Programmer  will  be  estab¬ 
lished  within  the  current  programming  division 
of  OP-094.  This  office  will  affect  the  transition 
to  Copernicus  programmatically  (versus  from 
an  engineering  standpoint)  from  stove  pipe  pro¬ 
grams  of  today  to  three  basic  types  in  the  future: 
1)  building  block  programs,  2)  pillar  programs, 
and  3)  Research,  Development,  Test  and  Evalu¬ 
ation  (RDT&E)  programs. 


This  Requirements  Definition  contains 
10  chapters  and  4  appendices.  Chapter  1  de¬ 
scribes  the  relationship  between  Space  andElec- 
tronic  Warfare  (SEW),  C4I  and  naval  command 
and  control.  It  provides  the  doctrinal  basis  for 
the  architecture.  Chapter  2  describes  eight  sys¬ 
temic  shortfalls  in  our  existing  architecture,  and 
Chapter  3  details  the  Copernicus  concept 

Chapters  4  through  7  discuss  each  of  the 
four  pillars  from  an  operational  perspective. 
Chapter  8  describes  the  technology—  the  build¬ 
ing  blocks  to  define  the  architecture  in  engineer¬ 
ing  terms.  Chapter  9  addresses  programmatic 
issues  and  provides  our  strategic  plans  for  POM 
development  Finally,  Chapter  10  details  our 
implementation  strategy  for  Phase  II  of  the 
Copernicus  Architecture. 
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CHAPTER  1 

DEFINITION  OF  NAVAL  C4I 


REFERENCES: 

(a)  JCS  Publication  3-02  (Joint  Doctrine  for  Amphibious  Operations) 

(b)  NWP  8  (Command  and  Control) 

(c)  NWP  10-1  (Composite  Warfare  Commander) 

(d)  NWP  10-1-40  (Electronic  Warfare  Coordination) 

(e)  NWP  10-1-41  (Navy  Operational  Deception  and  Counter  Deception) 

(f)  NWP  10-1-42  (Command,  Control,  and  Communications  Countermeasures) 

(g)  NWP  10-50  (Battle  Group  Communications) 

(h)  NWP  12-2  (Tactical  Threat  to  Naval  Surface  Forces) 

(i)  NWP  25  (The  SSN  in  Direct  Support). . 

(j)  Space  Tactics  Manual  (April  1989) 
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With  the  establishment  of  Space  and  Electronic  Warfare  (SEW)  as  a  designated  warfare  area  within  Navy  by  die 
Chief  of  Naval  Operations  in  1989,  command  and  control  (C2)  functions  have  been  doctrinally  designated  to  the  SEW 
mission.  Naval  Command  and  Control  is  the  warfare  function  through  whicha  maritimecommanderdelegates  warfighting 
responsibilities  to  subordinate  commanders  and  their  units  under  his  command.  Command  and  control  isexercised  through 
a  supporting  technological,  doctrinal,  and  organizational  system  known  today  as  command  and  control,  communications 
and  computers,  and  intelligence  (C4j).  C*I  should  be  viewed  as  the  means  to  the  end  of 

; C4I is  a  technological^ doctrinal,  and  organizational  support  system  that  facilitates  the  command  and  control  of 
forces  by  the  tactical  commando-.  Naval  C4! consists  of  three  components: 

*  Command  and  control,  which  in  the  Navy  is  embodied  in  the  carrier  battle  group  (CVBG)  Composite  Warfare 
Commander  (CWC)  doctrine,  in  the  submarine  force  deployment  and  watermanagement  doctrines,  and  in  the 
amphibious  doctrine—  all  evolutionary  outgrowths  of  World  War  II.  In  the  joint  task  forces  (JTF)  of  the  future, 
command  and  control  will  be  embedded  in  that  commander’s  doctrine,  which,  like  all  doctrine,  will  continue 

;  *  to  evolve  as  the  unified  commanders  and  the  Setvices  plan,  practice,  and  participate  in  joint  operations;  |||| 

*  Communications  and  computers,  the  modem  technological  “glue”  that  ties  the  commander  to  his  forces  and 
to  the  shore-based  intelligence  and  command  centers,  which  enables  information  management ;  and 

*  Intelligence,  which  in  the  context  o|  :p4I,  is  at  once  both  a  process  of  discerning  enemy  intentions  and 
capabiUties  arid  a  technological,  organizational,  and  a  Sensor  system  that  provides  much  of  the  information 
from  which  to  initiate  that  process. 

Todays  maritime  command  and  controlliS  embodied  in  five  forms;  four  of  which —  the  CVBO,  the  SSN  in 
independent  and  associated  support,  the  Marine  Air  GroundTaskForce  (MAGTF),  and  the  Amphibious  Taskforce  ( ATF) 
—  will  be  incorporated  into  this  architecture  in  the  near  future.  Strategic  (meaning  nuclear)  Command  and  Control  has 
unique  intelligence,communications,  and  command  requirements  thatneccssitatc  a  somewhat  different C4I  infrastructure 
than  non-nuclear  command  and  control.  While  the  Copernicus  Architecture  does  not  specifically  address  strategic 
Command  and  Control,  by  definition  strategic  Command  and  Control  will  ultimately  be  incorporated  into  Copernicus. 

We  should  consider  C*I  as  a  “triangular”  acronym,  with  Command  and  Control  at  the  apex  and  information 
management  (communications  and  computers)  and  intelligence  at  the  supporting  angles;  TO  enable  doctrinal  flexibility 
in  Command  and  Control,  it  is  critical  we  develop  aC4I  support  system  that  is  far  more  flexible  than  we  have  today.  It 
is  important  to  understand  that  flexibility  will  be  the  cornerstone  of  post-Cold  War  operations —  today’s  C4I  system  is 
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characterized  by  inflexibility.  Serious  limitations  both  in  information  management  and  in  intelligence  dissemination  are 
setting  unnecessary and artificial  limits son  command  and  control.  The  C*I  system  of  today  has  betxmretecbnotogicatty, 
doctrinally,  and  organizationally  obsolete. 

i^lflllpjpopernicus,  which  provides  the  doctrinal,  technological,  and  organizational  infrastructure  needed  to  weave  the 
modem  tactical  fabric  of  war  at  sea,  was  designed  to  replace  it 


DISCUSSION 

Naval  command  and  control  is  the  war¬ 
fare  function  through  which  a  maritime  com¬ 
mander  delegates  warfightingresponsibilitiesto 
subordinate  commanders  and  their  units  under 
his  command.  Command  and  control  is  exer¬ 
cised  through  a  supporting  technological,  doc¬ 
trinal,  and  organizational  system  known  today 
as  C4I.  C4I  should  be  viewed  as  the  means  to  the 
end  of  command  and  control. 

With  the  establishment  of  SEW  as  a 
designated  warfare  area  within  Navy  by  the 
Chief  of  Naval  Operations  in  1989,  command 
and  control  functions  (including  the  operation 
and  development  of  Navy’s  C4I  system)  have 
been  doctrinally  subordinated  to  the  SEW  mis¬ 
sion. 

SEW  is  the  destruction  or  neutralization 
of  enemy  targets  and  the  enhancementof  friendly 
force  battle  management  through  the  integrated 
employment  and  exploitation  of  the  electromag¬ 
netic  spectrum  and  the  medium  of  space.  It 
encompasses  measures  that  are  employed  to: 

•  Coordinate,  correlate,  fuse,  and  employ  aggregate 
communications,  surveillance,  reconnaissance,  data 
correlation,  classification,  targeting  and  electro¬ 
magnetic  attack  capabilities; 


•  Deny,  deceive,  disrupt,  destroy,  or  exploit  the 
enemy’s  capability  to  communicate,  surveil,  re- 
connoiter,  classify,  target,  and  attack;  and 

•  Direct  and  control  employment  of  friendly  forces. 

SEW,  COMMAND  AND  CONTROL,  AND  C4I 

Thus,  while  the  relationship  of  SEW  to 
Command  and  Control  and  C4I  is  hierarchal  in 
nature,  the  characteristics  of  each  are  different. 
Like  other  warfare  areas  (e.g..  Anti- Air  Warfare 
[AAW],  Anti-Submarine  Warfare  [ASW],  Strike 
Warfare  [STW]),  SEW  is  fundamentally  doctri¬ 
nal  in  nature,  but  (like  the  C4I,  a  subset  of  SEW) 
relies  on  a  broad  technological,  organizational 
and  doctrinal  infrastructure  to  execute  its  tacti¬ 
cal  functions:  C4I,  C4ICM,  ESM/ECM/ECCM, 
SIGINT,  SIGSEC1,  surveillance  and  counter- 
surveillance,  and  targeting  and  counter-target¬ 
ing. 

Like  all  naval  doctrine,  the  doctrine  of 
SEW  had  its  genesis  in  developments  in  technol¬ 
ogy  and  the  tactical  applications  of  that  technol¬ 
ogy.  As  AAW  and  ASW  arose  from  the 
development  of  the  aircraft  and  the  submarine, 

1  C^l  Countermeasures  (O^ICM),  Electronic  Support  Measures 
(ESM),  Electronic  Countermeasure  (ECM),  Electronic  Counter- 
Countermeasures  (ECCM),  Signals  Intelligence  (SIGINT),  Sig¬ 
nal  Security  (SIGSEC) 
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SEW  has  emerged  from  the  development  of 
technologies  over  the  last  two  decades  that  por¬ 
tend  the  promise  of  future  strategic  and  tactical 
breakthroughs. 


The  establishment  of  SEW,  therefore,  is 
the  doctrinal  recognition  of  the  maturity  of  these 
developments  and  of  the  paramount  importance 
of  managing  the  invisible  domain  of  the  spectra 
as  well  as  the  geography  of  space  in  the  next 
century.  (See  figure  1-1). 


Command  and  control  is  also  doctrinal 
in  nature,  supporting  as  it  does  all  of  the  com¬ 
manders  delegated  warfare  responsibilities  by 
the  tactical  commander.  Naval  command  and 
control,  as  we  shall  describe  below,  has  evolved 
parallel  to  the  technological  diversification  of 
naval  platforms  and  weapons,  which  have  moved 


from  operations  in  line-ahead  formations  on  the 
surface  of  the  world’s  oceans  to  the  complexity 
of  today. 

C4I,  on  the  other  hand  as  we  have  seen, 
is  a  technological,  doctrinal,  and  organizational 
support  system  that  facilitates  the  command  and 
control  of  forces  by  the  tactical  commander. 
Naval  C4I,  above  all,  is  a  system  that  consists  of 
three  components: 


•  Command  and  control,  which  in  Navy  is  embodied 
in  the  carrier  battle  group  CWC  doctrine,  in  the 
submarine  force  deployment  and  water  manage¬ 
ment  doctrines,  and  in  the  amphibious  doctrine — 
all  evolutionary  outgrowths  of  World  Warn.  In  the 
JTF  of  the  future,  command  and  control  will  be 
embedded  in  the  commander’s  doctrine,  which  like 
all  doctrine,  will  continue  to  evolve  as  the  unified 
commanders  and  the  Services  plan,  practice,  and 
participate  in  joint  operations; 


SEVy;Tedui<dogy  Systems;: 


•  Command  and  Control 


•  Communications  and 
Computers 
(Information  Mgmt) 


•  Intelligence  Display  and 
Dissemination 


Figure  1-L  Relationship  Between  SEW  and  Copernicus 
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*  Communications  and  computers,  the  modem  tech¬ 
nological  “glue”  that  ties  the  commander  to  his 
forces  and  to  die  shore-based  intelligence  and  com¬ 
mand  centers,  which  enable  information  manage¬ 
ment,  and 

•  Intelligence,  which,  in  the  context  of  C*I,  is  at  once 
both  a  process  of  discerning  enemy  intentions  and 
capabilities  and  a  technological,  organizational, 
and  sensor  system  that  provides  much  of  the  infor¬ 
mation  from  which  to  initiate  that  process. 

ORIGINS  OF  MODERN  NAVAL  C4I 

In  early  naval  warfare,  in  which  surface 
actions  were  the  sole  tactical  means  available  to 
the  commander,  command  and  control  was  ac¬ 
complished  through  an  understanding  reached 
between  the  commander  and  his  captains  of  the 
proposed  battle  plan.  The  best  example  of  this  is 
Lord  Nelson’s  famous  “band  of  brothers” —  the 
captains  with  whom  Nelson  discussed  his  inten¬ 
tions  prior  to  the  battle  and  in  whom  he  trusted 
would  carry  out  those  intentions  during  battle. 

Navies,  however,  are  inextricably  tied  to 
technology:  in  the  past  as  in  the  present,  weap¬ 
ons,  sensors,  and  tactics —  and  the  supporting 
C4I  systems —  are  all  reflections  of  the  technol¬ 
ogy  of  the  day.  Thus,  technology  can  either  add 
to,  or  detract  from,  both  command  and  control 
and  C4I. 

Modem  Naval  C4I  has  its  origins  in  the 
Pacific  campaigns  of  World  War  n,  where  the 
transition  from  surface  forces,  acting  in  line 
formations  operating  on  the  sea,  gave  way  to 
composite  forces  operating  in,  on,  over,  and 


under  the  sea.  The  impact  was  that  single¬ 
dimensional  battle  space  was  transitioned  tacti¬ 
cally  to  three  physical  dimensions. 

Equally  revolutionary  was  the  realiza¬ 
tion  that  the  advent  of  air  power  made  time  a  far 
more  significant  tactical  consideration  than  rela¬ 
tive  position,  the  centerpiece  of  surface  tactics  in 
the  preceding  25  centuries  of  seapower. 

The  tactical  and  doctrinal  impact  of  air 
power  was  to  aggregate  large  carrier  task  forces 
for  strike,  necessitating  delegation  of  warfighting 
functions  for  simultaneous  offense  and  defense, 
which  in  turn  placed  a  premium  on  distant  indi¬ 
cations  and  warning  of  enemy  formations  and 
intentions.  Surprise  at  sea — always  disadvanta¬ 
geous —  took  on  near-calamitous  proportions  in 
an  age  of  air  power  with  its  swift,  concentrated 
application  of  firepower. 

Out  of  World  War  n  arose  elements  of 
C4I  (see  figs.  1-2  and  1-3)  that  remain  with  us 
today: 

•  The  development  of  technological  sensor  systems 
to  provide  indications  and  warning  and  targeting 
information  to  the  commander  beyond  his  defen¬ 
sive  zone  and,  therefore,  act  to  “expand  the  battle 
space;” 

•  The  establishment  of  shore-based  intelligence  cen¬ 
ters  able  to  fuse  multi-sensor  information  and  turn 
the  information  around  to  the  commander  in  tacti¬ 
cally  significant  time; 

•  The  establishment  of  communications  networks  by 
which  to  transfer  the  intelligence  and  other  infor¬ 
mation  and  through  which  to  command  and  control 
tactical  forces;  and 
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Figure  1-3.  Evolution  of  Communications  Technology 
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*  The  transition  of  command  and  control  doctrine 
itself  from  surface  action  groups  to  multi-platform, 
multi-dimensional  task  forces. 

Command  and  control  doctrine  was  de¬ 
veloped  in  World  War  II  not  just  for  carrier  task 
forces,  of  course,  but  also  for  amphibious  forces 
and  for  submarine  operations.  In  both  cases, 
however,  the  elements  of  C4I  to  support  them 
remained  fundamentally  analogous  to  those  sup¬ 
porting  the  carrier  task  forces.  The  differences 
lay  in  the  applications  of  those  elements  to  those 
missions. 

Today,  maritime  command  and  control 
is  embodied  in  five  forms,  four  of  which —  the 
CVBG,  the  SSN  in  independent  and  associated 
support,  the  MAGTF,  and  the  ATF —  are  at  the 
heart  of  this  document,  which  proposes  a  new 
C4I  architecture  for  Navy  in  the  post-Cold  War. 
The  fifth  strategic  (meaning  nuclear)  command 
and  control,  has  unique  intelligence,  communi¬ 
cations,  and  command  requirements  that  neces¬ 
sitate  a  somewhat  different  C4I  infrastructure 
than  non-nuclear  command  and  control.  While 
the  Copernicus  Architecture  is  intended  ulti¬ 
mately  to  improve  strategic  command  and  con¬ 
trol,  such  planning  is  at  the  earliest  stages  at  this 
writing  and  not  discussed  in  this  document  fur¬ 
ther.  Similarily,  the  discussion  of  communica¬ 
tions  in  this  document  is  currently  limited  to  HF 
and  S  ATCOM  communications.  During  phase 
II,  submarine  operations  revelent  to  the 
Copernicus  architecture  will  be  determined  (see 
chapter  10).  During  that  effort  the  lower  fre¬ 
quency  will  be  considered. 


POST-COLD  WAR  COMMAND  AND  CONTROL 

Two  overarching  trends  in  maritime  war¬ 
fare  have  been  visible  from  the  development  of 
air  power  and  the  submarine  early  in  this  cen¬ 
tury.  First  has  been  the  increasing  expansion 
of  battle  space  brought  about  by  air  power  and 
the  advent  of  over-the-horizon  weapons.  Sec¬ 
ond  has  been  the  “systemization”  of  war  at  sea 
from  the  quasi-independent  tactical  action  of 
surface  action  groups  to  extraordinarily  com¬ 
plex  tactical  forces  of  today:  multiplatform, 
multidimensional,  and  multinational. 

The  impact  of  the  close  of  the  Cold  War 
on  both  developments  above  will  be  significant 
The  ever-increasing  battle  space,  characteristic 
of  global,  open  ocean  warfare  planned  for  in  the 
last  90  years —  in  reality  since  Alfred  Thayer 
Mahan —  has  given  way  to  post-Cold  War  era  of 
contingency  and  limited  objective  warfare 
(CALOW).  While  they  conceivably  can  occur 
in  open  ocean  environments  or  mixed  environ¬ 
ments  like  the  Falklands  conflict,  many  un¬ 
doubtedly  will  involve  power  projection  over¬ 
land  from  a  JTF.  Thus,  as  the  mission  becomes 
more  diverse,  battle  space  may  expand  or  con¬ 
tract  dramatically.  (See  fig.  1-4.) 

The  end  of  the  Cold  War  also  will  bring 
about  a  further  systemization  of  naval  warfare, 
not  Only  technologically,  but  organizationally, 
The  trend  toward  multiplatform,  multi¬ 
dimensional  naval  operations  begun  in  1943 
will  continue  to  accelerate  and  expand  in  the 
next  decade  to  joint  and  combined  (perhaps 
standing)  task  forces. 
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Figure  l-4f  Changing  Battle  Space 


As  a  result  of  these  developments,  the 
very  nature  of  war  at  sea  will  change  dramati¬ 
cally  over  the  next  decade;  threat,  alliances, 
geography,  technology,  and  resources  all  will  be 
catalysts. 

From  the  standpoint  of  command  and 
control,  we  will  need  to  develop  a  technological 
capability  to  implement  a  flexible  command  and 
control  doctrine  for  the  multiplicity  of  post-Cold 
War  missions.  With  a  45-year  focus  on  a  global, 
Soviet-oriented  threat.  Navy  command  and  con¬ 
trol  doctrine —  the  delegation  of  warfighting 
means  to  tactical  ends —  reflected  the  target: 
AS  W,  AAW,  and  STW  are  examples.  However, 
in  a  CALOW  mission,  command  and  control 
doctrine  will  not  only  be  delegated  across  a  JIF, 
of  which  Navy  units  will  only  be  one  compo¬ 


nent,  but  also  within  the  Navy  component,  there¬ 
fore  it  is  desirable  to  give  the  tactical  com¬ 
mander  doctrinal  flexibility  in  missions  where 
the  CWC  doctrine  is  not  appropriate. 

We  should  consider  C4I  as  a  “triangular” 
acronym,  with  command  and  control  at  the  apex 
and  information  management  (communications 
and  computers)  and  intelligence  at  the  support¬ 
ing  angles  (see  fig.  1-5).  To  enable  doctrinal 
flexibility  in  command  and  control,  it  is  critical 
we  develop  a  C4I  support  system  that  is  far  more 
flexible  than  we  have  today.  While  we  discuss 
shortfalls  in  the  current  architecture  in  the  next 
chapter,  it  is  important  to  understand  that  just  as 
flexibility  will  be  the  cornerstone  of  post-Cold 
War  operations —  today’s  C4I  system  is  charac¬ 
terized  by  serious  limitations  both  in  informa- 


1-8  •  Definition  of  Naval  C*I 


tion  management  and  in  intelligence  dissemina¬ 
tion.  The  C4I  system  pf  today  has  become 
technologically,  doctrinally,  and  organization¬ 
ally  obsolete. 

American  industrial  magnate  Henry 
Ford’s  enduring  achievement  was  not  the  Model 
TFord.  On  a  larger  scale,  it  was  the  technologi¬ 
cal  macro-system  surrounding  the  Model  TFord: 
the  assembly  line,  the  showroom,  the  gasoline 
station,  and  ultimately  the  infrastructure  of  roads. 
From  that  system  arose  a  change  in  our  culture. 
To  understand  the  invention  and  not  compre¬ 
hend  the  technological  system  required  to  utilize 
the  invention  is  to  miss  the  deeper  undercurrents 
of  the  first  industrial  revolution. 


electric  lights  possible.  Like  Ford,  Insull’s  tech¬ 
nological  system  had  a  broad,  enduring  cultural 
impact. 

So  too,  we  should  view  C4I  as  a  macro¬ 
system,  composed,  as  we  have  seen  above,  of 
command  and  control  doctrine,  information  man¬ 
agement  through  communications  and  comput¬ 
ers,  and  the  intelligence  and  sensor  processes. 

Copernicus  is  most  easily  grasped  when 
viewed,  like  Ford’s  automotive  and  Insull’s  elec¬ 
tric  technology,  as  a  new  technological  system 
for  C4I,  the  purpose  of  which  is  to  facilitate 
command  and  control  for  the  commander  at  sea, 
his  subordinates,  and  his  superiors. 


While  Thomas  Edison  can  be  credited 
with  the  invention  of  the  incandescent  light,  it 
remained  for  Samuel  Insull  of  Chicago  to  con¬ 
struct  the  technological  system  of  dynamos, 
power  stations,  and  transmission  lines  that  made 


Copernicus  arises  from  empiricism:  the 
technological  and  operational  conclusion  is  that 
today’s  C4I  “system”  is  not  hemorrhaging,  but 
that  the  patient  has  been  dead  for  some  years 
now. 
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While  the  “macro-system”  Copernicus 
consists  of  many  evolutionary  andrevolutionary 
components —  and  even  whole,  complex  sub¬ 
systems  such  as  the  Communications  Support 
System  discussed  in  Chapter  6 —  its  purpose  is 
to  provide  the  means  for  command  and  control 
functions  in  a  new  age  of  naval  warfare. 

Indeed,  it  may  not  be  an  exaggeration  to 
say  Copernicus  is  for  a  new  school  of  naval  -  - 
warriors.  Our  goal  with  Copernicus  is  to  provide 
a  21st  century  C4I  system  that  will  allow  these 
new  warriors  to  affect  the  tactical  innovations 
made  possible  by  high  technology. 

Copernicus,  then,  is  a  C4I  system  del¬ 
egated  to  the  Space  and  Electronic  Warfare 
Commander  (SEWQ  by  the  tactical  commander. 
However,  the  delegated  C4I  function  supports 
all  commanders — Copernicus  is  to  SEW  as 
Copernicus  is  to  AAW,  ASW,  ASUW,  and 
STW. 

Clearly,  however,  Copernicus  provides 
the  technological  means  by  which  the  tactical 
commander  can  take  advantage  of  the  nonror- 
ganic  sensors  that  SEW  doctrinally  provides. 

But  we  should  clearly  understand  that  a  particu¬ 
lar  CWC  commander’s  battle  domain,  in  terms 
of  time,  space,  and  capabilities,  is  primarily  a 
function  of  technology.  The  AAW  Commander 
exists  because  of  the  airplane;  the  ASW  Com¬ 
mander  because  of  the  submarine  and  ASW 
platforms.  The  Anti-Surface  Warfare  (ASUW) 
commander,  in  the  modem  context,  exists  be¬ 
cause  of  Harpoon  and  Tomahawk,  and  because 


of  the  threat  posed  by  die  enemy  through  such 
weapons. 

In  the  same  way,  the  SEWC  exists  be¬ 
cause  of  the  revolution  in  space  and  electronic 
warfare  technology  that  has  occurred  over  the 
last  20  years.  The  SEWC's  assets  are  as  tangible 
as  the  AAWC's—  it  is  simply  that  some  of  them 
are  not  physically  on  deck.  Copernicus,  relative 
to  the  SEWC's  functions,  gives  him  the  meaiis  to 
make  non-organic  sensors  organic. 

In  the  context  of  the  Navy  CVBG,  the 
introduction  of  SEW  has  greatly  expanded  the 
battle  space.  Figure  1-6  depicts  the  typical  battle 
space  in  which  the  organic  sensors  of  a  CVBG 
would  operate  and  therefore  represents  the  doc¬ 
trinal  and  practical  limitations  imposed  on  the 
tactical  commander  prior  to  the  delineation  of 
SEW  as  a  warfare  area. 


Figure  1-7  shows  the  potential  expansion 
of  CVBG  battle  space  made  possible  by  SEW  in 
an  open-ocean  scenario—  nearly  200  times  the 
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Figure  1-7.  CVBG  Battle  Space  with  SEW 


pre-SEW  space —  provided  organic  and  non- 
organic  sensors  are  organized  with  the  “shooters” 
into  a  capable  system  that  can  be  accessed  and 
manipulated  by  the  CWC  commanders. 

Doctrinally,  SEW  ismadepossible  within 
the  CWC  concept  through  the  emergence  of  a 
new  commander —  the  SEWC —  on  the  CWC’s 
staff  (see  fig.  1-7).  But  technologically,  the 
leverage  promised  by  a  more  modern 
systemization  of  sensors,  communications,  and 
ashore  and  afloat  fusion  nodes  has  eluded  us. 
We  cannot  conduct  SEW —  or  modem  ASUW, 
AAW,  ASW,  and  STW —  on  75-baud  or  even 
2400-baud  narrative  message  circuits. 


SEW  promises  to  bring  new  strategic 
tools  to  the  OTC,  which  arise  from  its  shore- 
based  component,  and  new  tactical  options  and 
perspectives  at  sea.  SEW  expands  the  tactical 
continuum  both  in  terms  of  time  and  space,  as 
figure  1-8  shows.  But  SEW — as  modem  AAW, 
ASUW,  STW,  and  ASW  —  is  to  a  great  degree 
dependent  on  making  non-organic  assets  more 
tangible  and  more  available  to  the  tactical 
commander. 

The  means  to  this  end  —  the  force 
multiplier  we  seek — is  C4I,  which  provides  the 
doctrinal,  technological,  and  organizational 
infrastructure  needed  to  weave  the  modem 
tactical  fabric  of  war  at  sea.  Copernicus  was 
designed  to  be  that  infrastructure. 
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Figure  1-8.  Five  Dimensions  of  Naval  Warfare 
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2-2  •  Shortfalls  in  the  Current  Architecture 


*  Sixth,  several  foctora--^  the  narrative  format,  the  lack  of  common,  display,  relative  versus  true  navigation 
iefMMKes,aplethoradf  computers,  and  staff  compromises—  have  resulted  in  a  significant  loss  of  operational 
§  |  p^pectivey/ith  respect  tb  sensor  traffic.  Architecturally  and  operationally,  the  goal  must  be  ohemrsjwrt  sensed 
leads  to  one  location  report  over  one  communications  path  to  sea  at  one  rime;  V":. 


and  disseminate  information  on  a  far  broader  category  of  potential:  threats; 

organizationally,  we  must  construct  an  intelligence  inftastructure  that  can  allow  a  Defense  Intelligence  Agency 

problem  to  be  in  contact  colleagues  in  Siite,  <!^f 

who  arealso  wpridngdaliiy  die  sameproblem  but  ftoffi  adUforent  angle.  And*  we  mult  move  tiiat  information 

to  sea  in  a  structured,  efficient,  tactical  context  on  short  notice;  and 


fimTRsivniTK? a mmcmvzr* m* 


and  displayintelligence  information.  Today,  data  file  transfer  to  sea  happens  by  flying  disks  onto  the  Carrier 
decks  hy  aircraft.  Tomorrow,  the  data  file  and  the  image  must  replaceiie  message  as  the  principal  Operational 
format.  Moreover,  the  data  file  and  image  must  be  displayed  and  tnilized  in  context  on  a  common  workstation, 
soth&anbpera^  is  achieved  between  sensor  tracks,  images,  and  analytic  files,  both  organic  and 

rum-organic,  can  be  achieved,. 


In  the  following  chapter,  we  will  return  to  these  problems  in  the  context  of  the  Copernicus  Architecture. 


DISCUSSION 

Perhaps  the  most  important  lesson  from 
the  history  of  naval  warfare  is  that  it  does  not 
teach  that  better  technology  prevails —  it  teaches 
that  he  who  uses  technology  better  or  he  who 
can  deny  the  other  technology  on  which  he 
depends,  prevails.  Marc  Antony  learned  that 
lesson  at  Actium  in  31  B.C;  we  learned  that 
lesson  in  Vietnam;  and  the  Soviets  learned  that 
lesson  again  in  Afghanistan. 

War  does  not  necessarily  favor  the  bel¬ 
ligerent  with  the  most  men  and  weapons.  Nor 
does  it  favor  the  one  with  the  latest  technology. 
Rather,  it  is  only  when  men,  weapons,  and 
technology  are  incorporated  together  in  an  op¬ 
erationally  and  doctrinally  sound  manner  does 
one  gain  an  advantage  over  an  opponent.  In 
modem  warfare,  the  superior  application  of  con¬ 
centrated  force  is  the  result  of  superior  com¬ 
mand  and  control  of  naval  systems. 


It  is  for  this  reason  that  it  is  important  to 
understand  the  historical  foundations  —  and 
therefore  the  systemic  functions — of  command 
and  control.  A  technological  development  with¬ 
out  a  corresponding  tactical  development  is  an 
idle  musing  in  the  naval  profession.  Technol¬ 
ogy  without  tactical  and  doctrinal  context  is 
merely  engineering  curiosity:  operationally  it  is 
a  force  divider. 

A  NEW  WORLD  ORDER 

The  likelihood  of  global  war  with  the 
Soviets  has  been  significantly  reduced.  U.S. 
strategic  emphasis  now  must  shift  from  global 
containment  to  a  global  stability  strategy  with  a 
regional  focus.  With  the  world  order  in  flux,  and 
the  continuingforecastof  fewerU.S.  navalforces 
in  the  future,  there  is  also  a  clear  need  for  a  naval 
policy  that  matches  means  to  ends.  Evolution¬ 
ary  concepts,  such  as  those  put  forth  by  the 


The  Copernicus  Architecture  •  2-3 


Copernicus  Architecture,  will  compensate  some¬ 
what  for  unavoidable  shrinking  force  levels  while 
providing  the  agility  for  a  genuine  multimission 
capability. 

America’s  economic  fate  is  linked  in¬ 
separably  to  the  fortunes  of  trading  partners, 
energy  suppliers,  capital  markets,  and  foreign 
industries.  The  United  States  must  remain  glo¬ 
bally  engaged  to  maintain  the  political  and  mili¬ 
tary  stability  upon  which  this  interdependent 
economic  system  rests.  Even  with  a  reduced 
global  Soviet  challenge,  potent  threats  to  U.S. 
security  remain  and  will  be  increasingly  am¬ 
biguous  in  the  future.  Even  with  so  much  ambi¬ 
guity  and  uncertainty,  it  is  clear  that  regional 
instability  will  be  the  main  threat  in  the  emerg¬ 
ing  geostrategic  environment 

Throughout  the  Cold  War,  military  plan¬ 
ning  focused  on  the  extreme  right  portion  of  the 


spectrum:  preparation  for  global  conventional 
war  and  strategic  nuclear  war  (see  fig.  2- 1 ).  The 
United  States  and  a  coalition  of  allies  pursued  a 
strategy  of  containment  of  the  Soviet  Union. 
Despite  the  low  probability  of  occurrence,  all 
planning  was  gready  influenced  by  the  worst- 
case  Soviet  threat,  including  a  “bolt  out  of  the 
blue”  attack.  In  the  past,  we  believed  that 
countering  the  Soviet  threat  inherentiy  prepared 
U.S.  forces  for  conflict  with  less  capable  adver¬ 
saries. 

In  reality,  even  while  the  national  strate¬ 
gic  spotlight  was  focused  on  a  Soviet  threat,  all 
of  the  Services  routinely  responded  to  threats 
and  contingencies  around  the  globe  at  both  ends 
of  the  spectrum  of  conflict.  Of  over 200 regional 
crises  that  naval  forces  responded  to  between 
1945  and  1989,  only  18  directly  involved  the 
Soviets. 
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Except  for  the  Soviets,  there  are  no  po¬ 
tential  adversaries  capable  of  conducting  a  glo¬ 
bal  military  campaign  against  the  United  States. 
Therefore,  nuclear  deterrence  of  the  SovietUnion 
will  continue  to  be  the  top  strategic  priority,  and 
sound  military  judgment  compels  the  U.S.  to 
remain  prepared  to  counter  the  Soviet’s  signifi¬ 
cant  conventional  military  capability.  But  the 
reduced  probability  of  such  a  confrontation  al¬ 
lows  a  shift  in  the  planning  focus. 

The  curve’s  new  plateau  (see  fig.  2-2) 
represents  the  increased  likelihood  of  instabil¬ 
ity,  crisis,  and  regional  conflict  outside  the  So- 
viet-U.S.  context.  Regional  instability  will  be 
the  primary  threat  to  global  economic  interde¬ 
pendence  and  U.S.  national  security  interests. 
The  United  States  must  plan  for  multiple,  unre¬ 
lated  crises  and  regional  conflicts  falling  under 
the  definition  of  Contingency  and  Low  Objec¬ 
tive  Warfare  (CALOW)  missions,  a  warfare 
environment  of  increasing  significance. 


Future  emphasis  must  be  on  stability 
operations  and  on  crises  that  can  occur  in  one  or 
more  regions  simultaneously  with  little  or  no 
warning.  U.S.  commanders  will  need  at  least  as 
much,  if  not  more,  flexibility  and  combat  power 
in  the  future  for  these  “come  as  you  are”  sce¬ 
narios.  Operational  tempos  will  take  on  a  joint 
and  combined  acceleration  (see  fig.  2-3).  Joint 
C4I  and  battle  management  will  be  a  prerequisite 
in  a  CALOW  environment  U.S.  forces  must  be 
able  to  control  the  battle  space  wherever  they 
operate — and  whatever  size  it  might  be.  As  we 
saw  in  the  previous  chapter,  one  implication  of 
the  post-Cold  War,  is  that  battle  space,  which  for 
naval  forces  has  been  expanding  for  90  years,  is 
now  far  more  unpredictable. 

CALOW  missions  will  expose  naval 
forces  to  a  plethora  of  opposing  weapon  systems 
on  an  extremely  complex  battlefield.  The  trend 
towards  higher  technology  weapons  will  de¬ 
mand  robust  close-in  and  overland  air  defense 


Figure  2-2.  Operational  Continuum  (1990-Beyond) 
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Figure  2-3.  Joint  Force  Sequencing  for  Maritime  Presence  and  Power  Projection 


and  a  connective  system  of  C4I  that  enhances 
joint  and  allied  capabilities —  and  that  can  keep 
pace  with  the  tactical  force  development  struc¬ 
ture  from  the  Carrier  Battle  Group  (CVBG)  to 
Joint  Task  Force  (JTF). 

Naval  forces  must  continue  to  develop 
resources  to  maintain  die  edge  against  increas¬ 
ingly  more  capable  adversaries.  Maintaining  the 
lead  in  advanced  technologies  is  critical  to  suc¬ 
cess  in  combat  Naval  forces  must  be  prepared 
for  instant  response  to  the  threat  posed  by  so¬ 
phisticated  First-World  weaponry  in  the  posses¬ 
sion  of  Third- World  adversaries.  Enhanced 
capabilities  in  battle  management  and 
interoperability  of  C4I  systems  are  and  will  be 
prerequisites  for  future  joint  and  combined  op¬ 
erations.  The  Copernicus  Architecture  was  con¬ 
structed  for  this  tactical  world  of  the  future. 


SHORTFALLS  IN  CURRENT  ARCHITECTURE 

Twenty  years  ago,  the  character  of  con¬ 
ventional  war  at  sea  once  more  fundamentally 
changed  and  did  so  as  dramatically  as  it  had  with 
the  advent  of  air  power  40  years  before.  Precipi¬ 
tated  by  tiie  Soviet’s  introduction  of  the  Charlie 
class  SSGN  in  1968  and  the  Soviet  Naval  Air 
doctrine  of  massed  attack  on  the  CVBG,  the 
importance  of  wide-area  surveillance  and  over- 
the-horizon  targeting  (OTH-T)  became  para¬ 
mount 

These  developments  dovetailed  with  the 
technological  development  of  national  sensors, 
put  in  place  largely  to  provide  Indications  and 
Warning  (I&W)  againstthe  Sovietnuclear  threat 
These  same  wide-area  sensors,  however,  when 
added  to  Navy-specific  sensors,  made  possible 
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ocean  surveillance  and  OTH-T,  the  develop¬ 
ment  of  which  became  the  focus  of  Navy  intel¬ 
ligence  and  sensor  organizations.  Because  of  the 
sensitivity  of  the  sensors  and  their  applications, 
much  of  the  work  was  accomplished  in  compart¬ 
ments  in  relative  isolation  from  the  "General 
Service"  (GENSER)  Navy. 

The  achievements  were  remarkable  and 
led  to  the  tactical  discussion  that  has  culminated 
today  in  the  establishment  of  Space  and  Elec¬ 
tronic  Warfare  (SEW)  doctrine.  However,  pen¬ 
alties  were  paid.  Sensor  products  proliferated  as 
diverse  operational  commands,  recognizing  their 
value,  demanded  it,  and  unnecessary  ambigu¬ 
ities  were  introduced  for  the  tactical  commander. 
It  is  a  fair  statement  to  say  that  the  ambiguities 
introduced  by  multiple  sensor  reports  created  an 
“iron  wall”  500  miles  distant  from  the  CVBG 
battle  space  that  was  delineated  by  the  limita¬ 
tions  of  organic  sensors,  perceived  as  more  re¬ 
liable  to  the  operators  shut  off  from  the  techno¬ 
logical  capabilities  behind  the  Sensitive  Com- 
partmented Information  (SCI)  “green door.”  The 
SCI  information  was  provided,  but  an  under¬ 
standing  of  the  technology  generally  was  not 

Moreover,  communications  nets  con¬ 
structed  by  the  sensor  and  intelligence  commu¬ 
nities  also  proliferated,  with  little  or  no  architec¬ 
tural  oversight  until  communications  capacity 
was  in  serious  shortage.  One  result  was  that  the 
components  of  C4I —  the  comers  of  the  triangle 
described  in  Chapter  1 —  began  to  grow  apart 
and  out  of  proportion  from  each  other  and  from 
the  whole  of  the  system. 


The  post-Cold  War  era  exacerbates  this 
problem.  While  we  have  over  40  years  experi¬ 
ence  developing  Soviet  intelligence  capabili¬ 
ties,  we  do  not  possess  an  agile,  capable  non- 
Soviet  intelligence  dissemination  capability, 
because  to  a  large  degree,  such  a  capability  is 
dependent  on  the  development  of  data  bases  and 
analytical  tools  not  readily  available  for  non- 
Soviet  targets.  Moreover,  most  of  the  Navy’s 
intelligence  sensors  are  neither  owned  nor  oper¬ 
ated  by  the  Navy.  Post-Cold  War  budgets  present 
to  the  Services  a  critical  problem  in  keeping  a 
tactical  influence  on  national  agencies  that  must 
face  large  cutbacks  in  resources. 

Programmatically,  many  of  today’s  C4I 
systems  were  procured  like  weapons  systems, 
which  are  expected  to  last  20  years.  The  down¬ 
side  to  this  is  that  technology  is  improving  at 
such  an  accelerated  rate  that  by  the  time  planned 
C4I  systems  are  introduced  into  the  fleet  they  are 
obsolete.  Many  sailors  operate  far  more  capable 
computer  systems  in  their  homes  than  in  their 
work  spaces.  End-to-end  systems  with  distinct 
hardware,  protocols,  software,  and  sponsors  are 
creating  logistical  and  training  pitfalls —  man¬ 
power  and  funding  we  can  no  longer  afford. 

Thus,  military  C4I  systems,  unless  we 
change  our  way  of  doing  business,  are  swim¬ 
ming  against  two  powerful  tides:  budget  cuts 
that  will  force  deep  reductions  in  funding  and 
manpower  needed  to  keep  equipment  operating 
and  technological  advances  that  make  computer 
generations  less  than  one-third  the  length  of  the 
acquisition  cycle. 
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The  upside  is  that  technology  is  chang¬ 
ing;  it  is  becoming  standardized  within  industry; 
and  it  portends  an  information  management  ca¬ 
pability  only  dreamed  about  before.  Systems 
that  cost  us  $250,000,000 in  the  1980s,  now  cost 
only  a  tenth  of  that  and  bring  with  them  stan¬ 
dards  as  well  as  improvements  in  size,  weight, 
and  electronic  reliability. 

From  the  standpoint  of  communications, 
we  are  in  a  dilemma.  Military  satellite  capacity 
already  is  significantly  behind  that  of  land-based 
capacity  (see  chap.  6).  As  data  speeds  increase 
to  fiber  optic  capabilities  ashore  and  on  ship¬ 
board  LANs,  satellite  throughputs  will  lag  rela¬ 
tive  to  systems  ashore  and  those  within  the  hull 
of  the  ship.  The  application  of  anti-jam  wave 
forms  further  reduces  the  potential  inherent  in 
Satellite  Communications  (SATCOM).  And 
High  Frequency  (HF),  while  suitable  for  narra¬ 
tive  traffic  and  for  intra-battle  group  communi¬ 
cations,  is  not  affordability  suited  for  data  rates 
above  1200  baud  and,  by  comparison,  is  man¬ 
power-intensive  to  operate. 

Moreover,  SATCOM  channels  can  be 
likened  to  personal  computers  before  the  advent 
of  operating  systems.  Access  to  the  channels 
serving  afloat  forces  is  rigid  and  inefficient 
SATCOM  channels  as  currently  designed  are 
not  dynamic  and  have  a  limited  surge  capability. 

Narrative  formats  cause  the  operator  to 
suffer  notfrom  a  lack  of  knowledge  but  from  the 
inability  to  assimilate  the  avalanche  of  informa¬ 
tion  being  sent,  much  of  which  is  repetitive.  The 
majority  of  the  data  is  sent  in  textual  format. 


What  little  machine-to-machine  traffic  we  do 
have  is  limited  by  diverse  protocols  and  data 
formats. 

FUNCTIONAL  PROBLEMS 

Perhaps  the  most  difficult  hurdle  to  leap 
in  constructing  a  new  C4I  architecture  like 
Copernicus  is  getting  the  right  level  of  focus. 
One  person’s  architecture  is  often  another 
person’s  multiplexer.  Today,  program  manag¬ 
ers  are  awash  in  acronyms,  while  operators  are 
drowning  in  installation  schedules  and  line  draw¬ 
ings. 

However,  as  we  step  away  from  today’s 
C4I  system  toward  tomorrow  ’  s  operational  prob¬ 
lem,  and  if  we  do  so  with  experience  and  under¬ 
standing  of  the  technology  both  behind  and  in 
front  of  the  compartmented  “green”  door,  a 
series  of  eight,  functional  shortfalls  emerge. 

In  discussing  them,  it  is  helpful  to  recall 
the  discussion  in  Chapter  1  of  C4I  as  a  system — 
a  “triangular  acronym”  with  command  and  con¬ 
trol  at  the  apex.  Command  and  control  has  to  do 
with  the  delegation  of  warfighting  means  to 
ends.  Ends,  of  course,  range  from  tactical  through 
strategic  to  political  in  nature.  It  is  characteristic 
of  the  post-Cold  War  that,  for  the  tactical  com¬ 
mander,  this  distance  between  tactical  ends  and 
political  ends  will  diminish  sharply. 

Communications  and  computers —  the 
second  “Command  and  Control”  of  the  acronym 
on  the  lower  left  of  the  triangle —  has  to  do  with 
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information  management.  Finally,  intelligence, 
on  the  lower  right,  not  only  has  to  do  with  the 
traditional  view  of  enemy  intentions  and  capa¬ 
bilities,  but,  in  the  last  20  years  it  also  has  come 
to  include  the  management  of  the  wide-area 
surveillance  systems  from  which  we  derive  so 
much  of  our  tactical  intelligence. 

Problem  1:  Command  and  Control  Inflexibility 

At  the  apex  of  the  triangle,  command  and 
control  itself,  the  first  functional  shortfall  today 
is  that  we  are  trying  to  absorb  the  threat  into  our 
existing  command  and  control  doctrine  instead 
of  taking  a  new  and  flexible  approach  to  com¬ 
mand  and  control  doctrine  based  upon  the  threat 

For  the  last  45  years,  each  of  the  Services 
has  developed  command  and  control  doctrines 
against  the  Soviet —  global  and  theater —  threat. 
The  Composite  Warfare  Commander  (CWC) 
concept  had  its  origins  in  World  War  II  and 
matured  to  the  current  concept  during  the  1 970s, 
but  its  focus  remained  the  same  for  4  decades — 
open-ocean  war  at  sea  with  a  sophisticated  naval 
foe.  Similarly,  the  AirLand  battle  doctrine 
adopted  by  Army  and  Air  Force  originated  in  the 
European  crucible  as  a  direct  outgrowth  of  the 
Soviet  Army  threat  and  its  similar  doctrine. 
Both  ground  and  air  forces,  NATO  and  the 
former  Warsaw  Pact  alike,  were  influenced — 
like  Navy’s  CWC  concept —  in  doctrine  devel¬ 
oped  during  World  War  n.  In  the  former  case, 
the  antecedent  was  the  German  Wehrmacht’s 
Blitzkrieg. 


The  world,  however,  has  changed. 
Single-service,  global-war-oriented  doctrines 
inevitably  will  give  way  to  or  be  modified  by 
both  the  sheer  diversity  of  the  CALOW  threats 
and  by  the  similar  diversity  in  task  force  compo¬ 
sition —  joint  and  allied,  and  different  allies 
today  than  tomorrow.  In  the  post-Cold  War, 
both  the  ends  and  means  of  each  mission  may  be 
different.  Therefore,  command  and  control  for 
the  new  age  must  offer  the  tactical  commander 
much  more  flexibility  than  today:  doctrinally, 
technologically,  and  organizationally. 

We  will  discuss  this  shortfall  in  detail  in 
the  next  chapter. 

Problems  2-6:  Information  Management 

Information  management —  communica¬ 
tions  and  computers —  poses  four  serious  func¬ 
tional  shortfalls. 

The  second  problem  is  that,  taken  in  the 
aggregate,  today  we  cannot  decant  operational 
traffic  from  administrative  traffic.  Therefore, 
when  we  go  to  war,  we  have  no  real  technologi¬ 
cal  means  to  gain  capacity  to  support  the  increased 
operational  tempo.  Indeed,  that  was  the  experi¬ 
ence  in  Desert  Storm  (see  fig.  2-4)  as  well  as 
every  major  exercise  for  the  last  two  decades. 

Literally  today, 33,000 commands  ashore 
can  send  the  tactical  commander  a  message  at 
their  collective  whim,  not  his.  All  the  com¬ 
mander  can  do  is  turn  his  radio  off. 
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Figure  2-4.  Message  Loading  During  Desert  Storm 


Third,  the  information  is  conveyed  in  the 
wrong  format —  narrative  messages,  and  in  the 
wrong  form —  paper.  It  should  not  surprise  us 
that  we  are  drowning  the  tactical  commanders. 
In  effect,  we  are  communicating  in  a  “pre-tele¬ 
vision  age.”  We  communicated  in  Desert  Storm 
in  the  same  way  we  communicated  in  the  desert 
storms  of  the  North  African  campaigns  50  years 
ago —  by  narrative  message.  Today,  we  tell  the 
ship  on  the  starboard  beam  1,000  yards  away  to 
replenish  us  tomorrow  by  sending  a  message 
back  to  the  beach  5,000  miles  away,  where  it  is 
returned  5,000  miles  back  to  sea  to  the  ship 
abeam. 

Tactically,  the  commander  at  sea,  in  ef¬ 
fect,  is  forced  to  read  the  equivalent  of  all  edi¬ 
tions  of  the  New  York  Times —  every  day,  every 
page,  every  column —  in  order  to  glean  the 
information  he  needs.  Moreover,  he  has  to  read 
all  the  editions,  some  of  which,  because  of 
delivery  delays,  are  received  out  of  sequence. 


And,  to  continue  the  analogy,  he  must 
remember  what  he  saw  on  page  6,  paragraph  15, 
line  4,  and  associate  it  with  the  society  page  and 
the  sports  page  to  correlate  it —  because  the 
editors  of  the  frontpage,  society  page,  and  sports 
page,  all  have  different  offices  in  town  and 
different  perspectives  on  the  problem. 

There  are  serious  implications  of  this 
reliance  on  narrative  traffic  to  communicate: 

•  It  is  necessary  for  the  tactical  commander  to  read 
narrative  in  order  to  gain  information,  recogniz¬ 
ing  as  we  must  the  two  are  not  the  same; 

•  Because  it  has  not  been  possible  in  the  past 
decade  for  the  commando’  to  read  all  the  traffic, 
much  discussion  has  arisen  about  an  apparent 
operational  issue  as  to  whether  to  fuse  ashore  or 
fuse  afloat  In  reality,  this  is  a  technological 
issue  as  well  as  an  operational  issue.  Although 
there  are  absolute  limits  on  how  much  can  be 
fusedateither  location  (e.g.,  security,  experience, 
manpower),  better  communications  andcomputer 
technology  can  lead  us  to  a  less  black  and  white 
choice.  Our  goal  should  be  simultaneous. 
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distributed  fusion  leading  to  a  consistent  tactical 
picture  ashore  and  afloat; 

•  Narrative  is  not  only  inefficient  from  an  informa¬ 

tional  standpoint,  but  also  from  a  communica¬ 
tions  perspective,  resulting  in  die  unnecessary 
waste  of  capacity.  Moreover,  this  is  not  only 
caused  by  the  technical  inefficiency  of  narrative 
transmission.  The  current  system  with  its  prolif¬ 
eration  of  messages  forces  on  the  tactical  com¬ 
mander  a  “push-it-all-at-you”  architecture  in¬ 
stead  of  facilitating  a  “pull-it-from-the-shelf” 
information  flow;  and 

■  Finally,  today's  narrative  is  the  technological 
and  human  bridge  between  organic  sensors  and 
non-organic  sensors.  Using  narrative,  arriving 
as  it  does  from  many  different  sources  and  path¬ 
ways  in  different  timeframes  (see  fig.  2-5),  intro¬ 
duces  a  redundancy  and  a  resulting  unnecessary 
ambiguity  to  die  tactical  picture.  Today,  that  is 
manifested  in  the  500-mile  tactical  wall  that 
represents  the  practical  limit  of  organic  CVBG 
sensors.  Breaking  down  that  wall  means  dis¬ 
playing  wide-area  sensor  locational  data  in  a  true 
navigational  display  side-by-side  with  organic 
informadon  on  the  same  screen.  The  effect  is  to 
render  non-organic  sensors  organic. 


Fourth,  the  current  system,  with  its  em¬ 
phasis  on  narrative  traffic  and  its  reflection  of 
diverse  sensors  and  analytic  nodes  ashore,  is 


Figure  2-5.  ELINT  Contact:  Multiple  Paths 


inefficient  What  traffic  goes  on  the  satellites  to 
the  tactical  commander  is,  today,  less  a  con¬ 
scious  operational  decision  than  an  administra¬ 
tive  decision  to  parcel  out  precious  communica¬ 
tions  capacity.  Thus,  the  tactical  traffic  is  more 
areflection  of  long-term  staff  compromises  than 
real-time  operational  requirements;  staff  wars 
versus  star  wars. 

Fifth,  the  technology  of  communications 
and  the  diversity  of  communications  bearer  ser¬ 
vices  is  inadequate.  We  must  develop  virtual 
networking  with  broad  choices  of  services,  both 
in  format  and  in  media.  This  shortfall  is  dis¬ 
cussed  at  length  in  Chapter  6. 

Sixth,  several  factors —  the  narrative 
format,  the  lack  of  common  display,  relative 
versus  true  navigation  references,  a  plethora  of 
computers,  and  staff  compromises —  have  re¬ 
sulted  in  loss  of  operational  perspective.  Archi¬ 
tecturally  and  operationally,  the  goal  must  be 
one  emission  sensed  leads  to  one  location  report 
over  one  communications  path  to  sea  at  one 
time. 


Like  the  novice  deck  officer  who  finally 
learns  to  abandon  the  maneuvering  board  for  the 
bridge  wing  during  his  first  turns  to  station,  we 
must  look  out  the  bridge  window  at  the  tracking 
problem.  In  open  ocean  warfare,  problems  do 
not  arise  instantly;  they  arise  over  a  time  and 
space  continuum  that  begins  with  indications 
and  warning  and  moves  closer  to  the  battle  group 
in  both  dimensions  through  cueing,  tracking, 
targeting,  engagement,  battle  damage  assess¬ 
ment,  and  re-engagement 
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The  current  system  does  not  allow  us  to 
reliably  develop  a  multisensor  track  on  a  tactical 
display  of  5,000  nm  (arbitrarily)  and  follow  it 
into  the  organic  sensor,  tactical  killing  zone  at 
500  nm  from  the  CVBG  center  with  a  minimum 
of  redundancy  and  ambiguity.  It  is  important  to 
realize  over  the  years  the  current  C4I  system  has 
become  so  complex  that  redundancy  and  ambi¬ 
guity  have  increased,  not  decreased. 

We  must  restore  operational  perspec¬ 
tive.  If  there  are  2,500  surface  ships  in  the 
Mediterranean,  of  which  250  must  be  tracked, 
and  a  total  of  5  organic  andnon-organic  sensors 
can  be  brought  to  bear  over  an  18-hour  tactical 
continuum  from  I&W  to  engagement,  the  amount 
of  communications  traffic  that  results  should 
have  a  direct  relationship  to  those  operational 
parameters.  In  other  words,  the  communica¬ 
tions  loading  should  reflect  some  model  of  250 
ships  x  number  of  emissions/18  hours  x  5  sen¬ 
sors. 

0*1  communications  loading  should  re¬ 
flect  the  enemy’s  actions,  our  actions,  and  the 
C4I  system  that  reports  those  to  us.  While  we 
cannot  always  control  the  first,  and  it  is  not 
desirable  to  limit  the  second,  we  can  bring  effi¬ 
ciencies  to  the  third.  C4I  should  decrease,  not 
increase,  the  fog  of  war. 

Problems  7  and  8:  Intelligence 

The  seventh  problem  in  today’s  C4I  sys¬ 
tem  is  presented  by  the  close  of  the  Cold  W ar  era: 
the  necessity  to  develop  and  disseminate  infor¬ 


mation  on  a  far  broader  category  of  potential 
threats.  This  challenge  goes  beyond  the  wide- 
area,  non-organic  sensors,  which  by  and  large 
can  be  tasked  against  Second  and  Third  World 
targets  as  well  as  the  Soviets.  It  goes  to  the  heart 
of  the  post-Cold  War  intelligence  problem: 

•  Where  is  the  threat? 

•  Who  is  die  ally? 

•  What  are  their  (both  ally  and  threat)  intentions 
and  capabilities? 

•  What  are  the  strategic  goals  of  the  mission  and 
how  do  we  measure  when  they  have  been 
achieved? 

Thus,  we  should  understand  that  the  new 
age  brings  us  full  bore  into  limited,  objective 
warfare.  The  intelligence  system  is  no  longer 
just  Navy,  nor  even  just  the  Department  of 
Defense.  It  includes  Government  agencies,  pos¬ 
sibly  multinational  corporations,  and  news  ser¬ 
vices.  In  a  world  of  diverse,  diffused  threat,  the 
intelligence  infrastructure  must  be  powerful, 
flexible,  and  able  to  reach  out  for  information 
quickly. 

Technologically,  doctrinally,  and  orga¬ 
nizationally,  we  must  construct  an  intelligence 
infrastructure  that  can  allow  a  DIA  analyst  as¬ 
signed  to  a  problem  to  be  in  contact  with  col¬ 
leagues  in  State,  CIA,  DIA,  and  industry  who  are 
also  working  daily  on  the  same  problem  from  a 
different  angle.  And,  we  must  move  that  infor¬ 
mation  to  sea  in  a  structured,  efficient,  tactical 
context  on  short  notice.  We  must  come  about 
from  a  Soviet-oriented,  single-Service-oriented 
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infrastructure  to  a  C ALO W -capable  infrastruc- 
*ure  one  which  can  respond  to  the  component 
commander  tactically  and  to  the  National  Com¬ 
mand  Authorities  strategically  within  the  same 
CALOW  battle  space. 

Eighth,  and  following  from  this  informa- 


cipal  operational  format.  Moreover,  the  data  file 
and  image  must  be  displayed  and  utilized  in 
operational  context  on  a  common  workstation, 
so  that  a  synergism  is  achieved  between  sensor 
tracks,  images,  and  analytic  files,  both  organic 
and  non-organic. 


tion  problem,  we  must  develop  the  means  to 
disseminate  and  display  intelligence  informa¬ 
tion  more  efficiently.  Today,  datafile  transfer  to 
sea  happens  by  flying  disks  onto  the  carrier 
decks  by  aircraft.  Tomorrow,  the  data  file  and 
the  image  must  replace  the  message  as  the  prin- 

Farce 

Deptojahent 


Figure  2-6  summarizes  the  eight  sys- 
temic  shortfalls  in  our  current  architecture.  In 
the  following  chapter,  we  will  return  to  these 
problems  in  the  context  of  the  Copernicus  Ar¬ 
chitecture. 
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available  under  Copernicus  is  to  determine  who  and  what  comprises —  technologically,  doctrinally,  and  organization¬ 
ally —  the  TCC  for  the  mission.  The  second  decision  includes  what  the  tactical  commander  will  delegate  tohis  "anchor" 
desks  in  the  CCC  ashore  and  what  will  he  retain  for  himself.  The  third  decision  the  tactical  commander  makes  is  who 
tnay  talk  to  him  ftpnt  the  GLOBIXS  iiifiastrifc  thire  is  an  information  management  ; 

isthe  network  (i.e.,  TADJXS)  mix?  Finally,  the  sixth  decision,  made  possible  through  the  Communications  Support 
System  (see  chap.  6);  is  to  select  cothmunications  pathway  or  bearer  services  for  the  virtual  nets. 


DISCUSSION 

The  Copernicus  Architecture  is  both  a 
new  C*I  architecture  to  replace  opr  current 
system  and  an  investment  strategy  that  provides 
a  programmatic  basis  to  construct  it  over  the 
next  decade.  The  remainder  of  this  document 
details  both  the  architecture  and  investment 
strategy  in  sequence. 

Chapters  4  through  7  discuss  the  four 
pillars  of  the  architecture:  the  GLOBIXS,  the 
CCC,  TADIXS,  and  the  TCC.  Through  the  four 
pillars,  Copernicus,  as  a  C*I  architecture,  will  be 
constructed  as  an  interactive  framework  that  ties 
together  the  command  and  control  process  of  the 
Navy  tactical  commander  afloat,  the  JTF  com¬ 
mander,  the  numbered  fleet  Commander  and 
others  with  the  CINCs  ashore.  Copernicus  has 
10  architectural  goals  shown  in  the  accompany¬ 
ing  boxed  text  3-1. 

GLOBIXS  are  global,  virtual  networks 
imposed  on  the  DCS  or  commercial  systems. 
GLOBIXS  tie  together  existing  shore  sensor 
nodes,  analytic  nodes,  and  other  selected  activi¬ 
ties  into  communities  of  like  interests.  They  are 
by  definition  joint  in  construction,  and  some  will 
be  combined.  Eight  strawman  GLOBIXS  are 
proposed;  however,  it  is  intended  and  is  archi¬ 
tecturally  desirable  that  the  number  and  nature 


of  GLOBIXS  be  flexible.  GLOBIXS  are  dis¬ 
cussed  in  detail  in  Chapter  4.  The  implementa¬ 
tion  of  the  GLOBIXS,  and  the  rest  of  the  archi¬ 
tecture,  is  described  in  Chapter  10. 

The  CCC  is  also  a  virtual  network,  im¬ 
posed  over  MANs  on  Oahu,  HI,  in  Norfolk,  VA, 
and  in  Naples,  Italy.  The  CCC  will  tie  together 
existing  command  and  staff  organizations  and 
proposes  to  construct  two  new  centers —  a  SEW 
center  and  a  research  center. 

Viewed  from  the  afloat  perspective,  the 
CCC  provides  a  means  to  manage  the  informa¬ 
tion  flow  for  the  tactical  commander,  with  suf¬ 
ficient  doctrinal  and  technological  flexibility  to 
allow  each  commander  to  decide  how  much  and 
what  kind  of  information  he  wants.  Thus,  the 
afloat  commander  should  see  the  CCC  as  a 
group  of  shore-based  assistants  somewhat 
analogous  to  the  CWC  in  the  CVBG  afloat  In 
the  same  way  CWC  commanders  are  delegated 
warfighting  ends  and  means  afloat,  the  CCC 
will  have  analogous  personnel  to  whom  ends 
and  means  ashore  may  be  delegated. 

Viewed  from  the  shore  perspective,  these 
CCC  personnel  are  similar  to  television  news 
anchor  desks.  They  “anchor”  each  GLOBIXS 
in  order  to  shape,  sort,  analyze,  and  move  the 
information  from  shore  to  ship  and  from  ship  to 
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Boxed  Text3'E:  Ten:  Architectural  Goats  of  the  Copernicus  Architecture 

.1.  Technological,  organizational,  and  doctrinal  flexibility  to  accommodate  open  ocean  operations,  prolonged 
4:i.  regional  conflict,  and  crisis  action; 

!!!!•  progjaira,;Md^sure  new  pipgjsuns  are:  part 

3.  Centralized  architectural  development  and  oversight  with  standardized  technological  components  ^ind  ••••.. 

|4|  consolidated,  operational,  tacticalnetworks; 

4.  Decentralized  development  of  mission-spedfie,  multimedia,  global  networks  within  the  blueprint  to  maximize 
experience  and  innovation  down-echelon; 

5.  Analogous  cxnxmiandcentersashrreandaflaat  that  sharea  consistent  tactical  pichirerand;ajnnect  Navyto  the 

joint  and  allied  picture; 

6.  Marriage  of  national  assets  to  tactical  applications;  the  accommodation  of  SEW; 

.4  74  A  new  lc^stks  sltr^e^  -  Pfii  -  to  ki^p  the  lradiirig  edge  t>£  teehriblogy  in  the  fleet  »»hile  reducing  the  Navy  l|isf  ffl 
4  and  maintenance  tail; 

4 1 £  An  end  to  domination  of  the  Navy  communications  by  the  message  format;  an  approach  to  true  office  automation; 

9.  Both  functional  and  technological  consolidation  of  military  SATCOM  bandwidth  and  an  affordable  high-data  • 

’  rate  alternative  to  It;  and  \  .4  '  '  • ..  .■  .'-4  4  ^ 

IQ.  Better  security  through  MLS  in  the  intelligence  fusion  process,  elimination  of  hardcopy  olographic  (i.e.> 

Over-the-Air  RekeyingtOTARl  and  Over-the-Air  Transfer  [OTATl),  and  establishment  of  a  Navy-wide  secure 
SDT&E  network. 


shore  (see  fig.  3-1).  They  are  the  tactical  gate¬ 
ways  to  the  fleet  for  the  shore  communities. 
CCCs,  which  may  be  either  Navy  only  or  uni¬ 
fied  in  construct,  are  discussed  in  Chapter  5. 

The  TADIXS  are  a  series  of  virtual  nets 
that  link:  1 )  the  afloat  commander  with  the  CCC 


hours,  5  days)  depending  on  the  information 
exchange  load.  TADIXS  should  not  be  consid¬ 
ered  communications  circuits;  but  information 
networks  sharing  communications  circuitry  over 
a  broad  menu  of  bearer  services  from  HF  and 
VHF  to  UHF,  SHF,  and  EHF  military  satellites 
to  commercial  satellites.1 


(and,  by  extension,  to  the  National  Command 
Authorities,  allies,  and  Government  agencies); 
2)  the  afloat  commander  to  units  under  his 
command;  3)  the  component  commander  to  the 
JTF  commander;  and  4)  the  afloat  commander 
to  the  wide-area  sensors  managed  ashore  that 
are  not  routed  through  the  CCC  (e.g.,  direct 
targeting  TADIXS  [see  chap.  6]). 

Copemican  TADIXS  are  not  to  be  con¬ 
fused  with  the  existing  TADIXS  A  and  B. 
Rather,  Copemican  TADIXS  are  virtual  net¬ 
works  of  variable  duration  (e.g.,  5  minutes,  5 


1  For  purposes  of  this  document,  we  should  differentiate  among 
the  terms  "bearer  services,"  "communications  services,"  "com¬ 
munications  circuits,"  and  "information  networks."  See  fig.  3- 
2.  A  bearer  service  is  aphysical  transmission  system  (e.g.,  fiber 
optic  cable,  digital  microwave,  or  satellite  transmission  path.)  A 
communication  service  is  data  (e.g.,  voice,  data  file  transfer, 
message,  image)  that  is  sent  over  bearer  services.  A  communi¬ 
cation  circuit  defines  a  specific  pathway  over  a  bearer  service 
(e.g.,  channel  one,  UHF  FLTSATCOM.)  An  information  net¬ 
work  is  analogous  to  yesterday's  telephone  party  lines;  it  is  the 
means  by  which  different  users  convey  information  to  one 
another. 

Thus,  in  the  context  of  Copernicus,  a  TADIXS  is  an 
information  network  (i.e.,  users  in  a  community  of  interest)  that 
conveys  one  or  several  communications  services  (e.g.,  voice, 
data  files)  over  a  communications  circuit  of  a  bearer  service. 
TADIXS  can  be  thought  of,  then,  as  having  temporal  nomencla¬ 
tures:  ASW/data/ch.  4/UHF;  ASW/voice/ch.  1SHF;  or  ASW/ 
imagery/ch.  1/INMARSAT.  The  duration  of  the  temporal 
TADIXS  is  a  function  of  information  load  and  tactical  situation. 
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Figiire  3-1.  CCC  Anchors  i 
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TADIXS,  then,  are  not  communications 
constructs,  but  operational  constructs,  which  is  a 
concept  alien  to  our  current  C*I  system  but 
familiar  in  industry.  TADIXS  are  discussed  in 
Chapter  6. 

The  final  pillar  of  the  architecture  is  the 
TCC,  which  is  intended  to  be  a  generic  term 
reflecting  the  decision  centers  of  warfighting 

commanders  —  whether  in  carriers  {seefig.-3-~  - . 

3),  submarines,  or  the  MAGTF  in  the  Navy- 
Marine  model  or  Corps,  Air  Wings,  and  JTF  in 
the  joint  model.  At  the  heart  of  the  concept  of  the 
TCC  are  two  technological  goals. 

First,  the  TCC  should  be  designed  as  an 
open  systems  architecture  based  on  standards  to 


create  a  modular  environment  that  can  be 
configured  for  many  missions,  not  just  one. 
Today,  we  sit  in  front  of  an  electronic  warfare, 
imagery,  or  data  base  terminal.  Tomorrow,  all 
terminals  will  be  the  same,  but  each  can  be 
configured  by  software  to  accept  information 
from  many  sources  and  display  it  on  a  human- 
machine  interface  (HMI)  software  application 
that  provides  operational  context  and  decision¬ 
making  tools.*  Technological  standards  are 
discussed  in  Chapter  8. 

Second,  through  this  flexibility,  the 
tactical  commander  can  construct  his  TCC  — 
and  his  wardroom — to  reflect  the  mission  rather 
than  shoe-homing  the  mission  into  a  fixed 


Figure  3-3.  What  is  a  TCC? 
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technological  configuration2.  TCCs  are  FOCUS  ON  THE  OPERATOR 

discussed  in  Chapter  7.  Figure  3-4  shows  the 

interconnectivity  among  the  four  pillars  using  Copernicus  focuses  on  the  operator  at 

ASW  as  an  example.  four  levels: 


2  Thus,  somewhat  paradoxically,  we  come  around  full  circle  in 
command  and  control.  In  Lord  Nelson’s  time,  technology  was 
brought  to  die  tactical  problem  through  an  intuitive  process  by 
which  Nelson  conveyed  his  intentions  beforehand  to  his  cap¬ 
tains.  The  captains  then  took  their  ships  into  the  fray.  This 
concept  was  carried  through  for  175  years  inta  today's  “CWC  ~ 
concept 

However,  with  the  rapid  growth  of  workstations  and  com¬ 
mand  and  control  technology  in  die  last  two  decades,  a  trend 
toward  fixed-workstation  positions  has  materialized  -  ELINT, 
SIGINT,  imagery,  and  so  on.  This  portends  a  move  away  from 
command  and  control  as  an  operational  construct  built  from  the 
tactical  commander’s  view  of  the  mission  toward  a  command 
and  control  that  reflects  an  existing  technological  configuration 
that  has  resulted  no t  from  operational  but  from  programming  and 
engineering  considerations.  Central  to  the  Copemican  diesis  is 
die  operator — not  the  programmer,  communicator,  or  engineer 
-  is  in  tactical  command,  and  the  operator  should  be  provided  the 
technological,  doctrinal,  and  organization  means  to  construct 
C4!  to  support  his  command  and  control  needs. 


•  The  watchstander,  through  the  employment  of 
common,  and  high-technology,  computer  work¬ 
stations3  that  are  identical  from  station  to  sta¬ 
tion — and  pillar  to  pillar —  except  for  a  mission- 
specific  software  “veneer”  that  delineates  the 
communities  of  interests.  Using  this  worksta¬ 
tion,  the  Anti-submarine  Warfare  (ASW)  ana¬ 
lyst  in  the  GLOBDCS,  the  ASW  anchor  at  the 
CCC,  the  ASW  TADIXS  subscribers,  and  the 
ASW  commander  in  the  TCC  all  share  a  com¬ 
mon  HMI  hosted  on  identical  terminals  (see  fig. 
3-5); 

•  The  Navy  tactical  commander,  through  the  em¬ 
ployment  of  the  virtual  TADIXS,  the  number 

3  Called  Fleet  All-Source  Tactical  Terminals  or  FASTTs. 


The  Copernicus  Architecture  •  3-7 


COTS  Software 

xindcv  x  Windows,  motif 

•  Digital/terraiiunaps 

"  ♦  Imagery  processing boards; 

:  *  High-speed  toct  search 

|||§||ai^ 

♦  DBMS 

*  DOS  emulation 

*  Word  Processing 


MissionVeneer 


/,  GOTS  , 

rif .  cots 


. -GOTS Software  |g . ;*!R|f 

*  Panther/PAWS.cotrelatioru—,-  _<■  <  .  ;-v-v-. 

•  MUDS/IDB  reference  data  bases 

«  Trusted  port  software  ('Trans-sanitization!')  ; 


GLOBDCS/TADIXS  Analytical  software 

IIBIIIIIIPI  Figure  3-5. ;  Off-the-shelf,  DTC-2-based  FASTE 


and  nature  of  which  are  changeable  to  suit  his 
command  and  control  doctrinal  decisions,  and 
through  the  configurable  TCC.  The  TADIXS 
and  the  TCC  allow  one  commander  to  shape  his 
command  and  control  one  way  and  another  com¬ 
mander  in  the  same  theater  to  shape  his  a  differ¬ 
ent  way; 

The  JTF  commander,  who  in  the  post-Cold  War 
command  structure  likely  will  emerge  as  the  on¬ 
scene  tactical  commander  in  many  actions, 
through  the  development  of  an  architectural  ca¬ 
pability  to  size,  shape,  and  scope  many  diverse 
shore  and  tactical  components  into  the  -  - 
GLOBIXS-TADIXS  model  of  Copernicus;  and 

The  shore  commander,  from  the  Fleet  Com¬ 
mander  in  Chief  (FLTCINQ  to  the  unified  CINC 
to  the  National  Command  Authorities  (NCA), 
through  the  development  of  a  broad,  high-tech¬ 
nology  commandconnectivity(e.g.,  video,  voice, 
narrative)  and  through  the  establishment  of  the 
rapidly  configurable  GLOBIXS  that  can  tie  the 
commander  to  all  echelons,  across  all  Services, 
to  all  allies  (whether  temporary  or  enduring),  and 
across  the  spectrum  of  warfare. 


INFORMATION  FLOW 

It  is  important  to  understand  how 
Copernicus  seeks  to  differentiate  data  from  in¬ 
formation  and  to  emphasize  the  latter  over  the 
former  (see  fig.  3-6).  For  our  purposes,  data 
happens  “below”  the  HMI  of  the  tactical  termi¬ 
nals.  Information  is  data  displayed  within  the 
operational  context  provided  by  the  HMI.  Sig¬ 
nals  Intelligence  (SIGINT)  locational  data,  for 
example,  is  ASW  information  when  placed  in 
the  operational. context  of  the  ASW  problem. 
While  this  may  seem  at  first  glance  to  be  an 
esoteric  delineation,  on  further  reflection  it  en¬ 
ables  us  to  consider  more  easily  the  nature  and 
efficiencies  of  transmitting  data  and  the  multiple 
opportunities  of  sending  data  to  different  users 
with  different  contexts.  Simply  put,  we  can  use 
this  construct  to  define  data  as  a  raw  material — 
a  commodity —  that  contributes  to  operational 
information. 
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Figure  3-6.  Data/Information  Interface 


In  Copernicus,  data  is  forwarded  to  the  precedence  and  is  typically  in  the  form  of  a 

tactical  commander  from  ashore  and  from  the  sensor  location  report  in  a  binary  format  or  a 

tactical  commander  to  shore  (and  all  subscribers  voice  report  Case  1  data  originates  from  sensor 

in  between)  and  is  differentiated  by  two  factors.  nodes  ashore  and  afloat.  These  sensors  may  be 

The  first  is  precedence;  the  second  is  format  “toggled” onoroff— senttoatacticalcommander 

or  not —  at  the  commander’s  discretion  (see  fig. 
3-7).  If  the  tactical  commander  decides  to  toggle 
Cases  of  Data  off  a  sensor,  the  sensor  report  nevertheless 


By  precedence,  we  mean  three  cases  of  4_  .  ,  J 

*  The  immediate  Case  1  data  requirement  is  defined  as  less  than 
data.  Case  1  data  is  defined  as  immediate^  in  3  minutes  from  the  sensor  to  the  user. 


Partial  Battle  Group  GtOBIXS  Toggles  by  Cast* 


•  CASE  1  -  Sensor  data  ®  CASE  2  -  Value-added  O  CASE  3  -  Non-time  Sensitive 


User  Software 


Copernicus  Tactical  Software 


OPS  Layering  TADIXS/GLOBIXS 

Operating  System  e.g.,  CSS 

Protocols /Standards  e.g.,X.400 
Transmission  Media  e.g.,  DDN,  SATCOM,  IC2 


Figure  3-7.CopernictisC,I  Planning 


The  Copernicus  Architecture  •  3-9 


would  be  monitored  by  the  appropriate 
GLOBIXS  anchor. 

Technologically,  this  is  achieved  by  con¬ 
verting  the  sensor  locational  reports  into  binary 
packets  (see  chap.  4)  and  addressing  the  packets 
to  those  commanders  who  desire  them  (see  figs. 
3-8  through  3- 10)5.  Doctrinally,  this  is  antici¬ 
pated  to  be  a  choice  from  a  communication 
services  matrix  to  be  contained  in  a  future-  Co* — 
pemicus  NWP.  (We  will  return  to  this  concept 
in  the  section  “Copernicus  Doctrine”  below.) 

Thus,  it  is  possible  for  tactical  com¬ 
mander  A  and  tactical  commander  B  to  make 
separate  decisions  about  how  Case  1  data  is 

5  Certain  sensors  require  data  transmission.  Such  sensors  may 
not  be  able  to  use  packet  switching.  With  those  cases,  dedicated 
circuits  will  be  necessary. 


received  and  which  Case  1  data  to  receive  even 
if  they  are  steaming  in  formation  together  side- 
by-side. 

Moreover,  since  the  terminals  of  the  TCC 
are  configurable  in  both  Battle  Groups,  and  the 
data  may  be  addressed  (or  not)  to  any  terminal, 
each  Battle  Group  commander  may  decide  dif¬ 
ferently  who  will  get  which  data.  We  therefore 
can  achieve  technological  standardization  with¬ 
out  operational  rigidity. 

Because  the  operator  is  in  the  center  of 
the  Copemican  universe  and  makes  decisions  to 
aggregate  dataintooperational  information  (e.g., 
locational  data  into  tracks),  and  because  this  is 
an  art  dependent  on  experience,  manpower,  per¬ 
spective,  and  other  factors,  we  must  provide 
compensation  for  lack  of  those  factors  afloat  (or 
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ashore).  Case  2  data  is  intended  to  provide  value- 
added  to  Case  1  data  and  provide  that  compensa¬ 
tion  in  near-immediate  time.6 

Case  2  data  may  originate  from  sensor 
nodes,  but  more  typically  from  analytic  nodes 
ashore  and  from  other  tactical  units.  Case  2  data 
typically  will  be  in  the  form  of  OPNOTES  and 
voice  reports  over  the  GLOBIXS-TADIXS  net¬ 
works;  however,  data  files  and  imagery  are  also 
likely  formats. 


Case  3  data  is  “term”  data:  data  that  is 
not  time-sensitive,  relative  to  Case  1  and  Case  2. 
Itis  anticipated  that  Case  3  data  will  be  data  with 
a  time-transmittal  requirement  of  less  than  3 
hours;  however,  ultimate  definition  of  sub-cat¬ 
egories  of  Case  3  data  with  different  timeframes 
are  probable  during  Phase  II  of  Copernicus 
development  (see  chap.  10). 

Operational  Formats 


Like  Case  1  data.  Case  2  data  may  also  be 
toggled  on  or  off  dynamically  over  time  and  is 
envisioned  to  be  part  of  a  doctrinal  process 
described  in  the  future  Copernicus  NWP. 

^  The  near-immediate  requirement  is  defined  as  less  than  15 
minutes  between  nodes. 


By  operational  formats,  we  mean  eight 
types  of  communications  services  (see  footnote 
1):  voice,  OPNOTE,  narrative  message,  fac¬ 
simile,  Copernicus  Common  Format 
(COPCOM),  data  base  files,  imagery,  and  video. 
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Voice  is  self-explanatory.  OPNOTEisa 
short,  interactive,  analyst-to-analyst  exchange 
similar  to  E-mail.  Narrative  messages  are  the 
existing  character-oriented  formats.  COPCOM 
is  a  sensor  locational  report  that  has  been  trans¬ 
literated  into  a  standard,  binary  format  (see 
chap.  4).  Data  files,  imagery,  and  video  are  also 
binary  formats. 

Using  these  data  formats  and  coupling 
them  with  the  precedence  cases,  we  can  define 
the  communications  services  for  each  of  the 
virtual  networks  of  the  four  pillars.  See  figure  3- 
1 1  for  a  matrix  of  those  services. 

In  constructing  the  communications  pil¬ 
lars,  it  becomes  possible  to  develop  a  taxonomy 
that  describes  five  characteristics  of  the  pillars 


—  bearer  services,  communications  circuits, 
communications  services  (i.e.,  format),  and  in¬ 
formation  networks  (i.e.,  subscribership)  and 
precedence  (i.e.,  case).  It  is  important  to  recog¬ 
nize  that  while  it  is  possible  to  describe  require¬ 
ments  for  the  pillars  in  these  terms,  such  require¬ 
ments  must  be  both  generalized  and  instanta¬ 
neous  because  several  of  the  characteristics  are 
variable  with  time.  Figure  3-12  shows  the  tax¬ 
onomy  for  an  ASW  GLOBIXS,  and  figure  3-13 
showsasimilartaxonomyfortheASWTADIXS. 

Information  flow  ashore  is  discussed  in 
Chapter  4.  Afloat  information  flow  is  discussed 
in  Chapter  6.  Taxonomic  requirements  for  each 
pillar  will  be  discussed  in  their  respective  chap¬ 
ters. 
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COPERNICUS  COMMAND  AND  CONTROL 
DOCTRINE 

In  the  previous  chapter  on  shortfalls  in 
the  current  architecture,  we  discussed  eight  sys¬ 
temic  0*1  problems.  Today  with  an  eye  toward 
those  problems,  let  us  examine  how  the 
Copernicus  Architecture  will  change  command 
and  control. 


Copernicus  provides  the  tactical  com¬ 
mander  with  six  doctrinal  choices  that  allow  him 
to  construct  his  command  and  control  to  support 
the  mission  and  his  decision  to  delegate  forces  to 
carry  out  that  mission.  In  doctrinal  sequence, 
they  are  described  below  and  in  figure  3-14. 

During  the  planning  stage  of  an  opera¬ 
tion,  the  tactical  commander  must  make  a  deter- 
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minadon  as  to  what  forces  to  use  and  who  to 
delegate  the  forces  to.  To  facilitate  and  parallel 
that  decision,  the  commander  will  configure  the 
TCC  (and,  by  extension,  the  TCCs  of  units  under 
his  control)  to  reflect  his  plan.  Thus,  the  first 
decision  under  Copernicus  is  to  determine  who 
and  what  comprises —  technologically,  doctri- 
nally,  and  organizationally —  the  TCC  for  the 
mission. 

What  are  the  operational  tasks  in  the 
execution  order  for  the  mission?  To  whom  will 
the  tactical  commander  delegate  those  tasks? 
Implicit  in  these  decisions  is  a  technological 
flexibility  that  allows  one  delegated  commander 
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Figure  3-14.  Copernicus  NWP  ehoices 


to  do  one  task  in  one  mission  and  a  different  task 
elsewhere  (or  at  another  time  in  the  same  mis¬ 
sion). 

The  second  decision  is,  what  will  the 
tactical  commander  delegate  to  his  anchor  desks 
in  the  CCC  ashore,  and  what  will  he  retain  for 
himself?  One  commander  may  want  all  infor¬ 
mation  to  be  sent  to  him;  another  may  want  some 
information  in  one  category  and  all  information 
in  another,  a  third  may  want  the  anchor  to  watch 
all  information  500  miles  from  the  task  force  and 
provide  periodic  reports.  These  delegation  deci¬ 
sion  are  both  personal  and  scenario-driven.  It 
may  even  be  a  personality-driven  one —  does  he 
have  more  confidence  in  the  shore  imagery 
anchor  than  the  intelligence  officer  afloat? 

Now  that  a  decision  has  been  made  about 
who  is  doing  what  afloat  and  ashore,  behind  the 
anchor  desks  we  constructed  the  anchor’ s  shore- 
based  organization —  the  GLOBIXS.  The  third 
decision  the  tactical  commander  makes  is  who 
may  talk  to  him  from  the  GLOBIXS  infrastruc¬ 
ture  and  in  what  cases  (i.e.,  when).  This  decision 
is  not  monolithic.  The  tactical  commander  may 
delegate  the  decision  to  one  anchor,  but  not 
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another.  He  may  also  change  the  decision  by 
moving  to  a  different  “toggle”  setup  in  a 
GLOBIXS  as  the  mission  changes. 

Thus,  instead  of 33, 000 commands  push¬ 
ing  messages  onto  the  tactical  commander,  the 
primarily  binary  data  is  aggregated  through 
GLOBIXS  gateways  managed  by  the  anchors 
who  respond  to  the  tactical  commander’s  del¬ 
egation.  Fundamentally,  then,  Copernicus  is 
not  a  “push-it-all-at-you”  architecturej-it  ■ 
“pull-it-firom-the-shelf-as-you-want-it”  architec¬ 
ture. 

Now  that  the  commander  has  exercised 
command  and  control  by  delegating  functions 
both  afloat  and  ashore —  a  revolutionary  pro¬ 
cess  made  possible  by  the  GLOBIXS —  there  is 
an  information  management  decision:  who  gets 
what  information!1  This  fourth  decision  returns 
us  to  the  discussion  of  data  versus  information. 

It  is  a  doctrinal  decision  made  possible  techno¬ 
logically  by  selecting  communications  services 
from  figure  3-11  and  addressing  them  to  the 
chosen  units  and  TCC  positions. 

The  fifth  decision  is  the  instantaneous 
construction  of  the  virtual  information  net¬ 
works —  what  is  the  network  (i.e.,  TADIXS) 
mix?  Now  that  the  tactical  commander  has 
decided  who  will  talk  to  whom  and  in  what 
circumstance,  he  decides  how  they  will  talk.  In 
the  Copernicus  Architecture,  this  decision  is  not 
wholly  a  communications  circuit  and  bearer 
service  decision.  See  figure  3-15. 

1  Inherent  in  this  decision  is  the  security  issue  of  authorization 
of  access  to  the  data. 


The  decision  about  how  many  TADIXS 
has  to  do  equally  with  what  kind  of  communica¬ 
tions  services  are  pulled  from  the  shelf  and  how 
many.  Communications  services  for  a  TADIXS 
may  be  provided  over  a  single  communications 
circuit  in  some  cases,  and  communication  ser¬ 
vices  of  more  than  one  TADIXS  may  be  pro¬ 
vided  over  the  same/common  communications 
circuit  in  a  time  or  frequency  multiplexed  man¬ 
ner.  A  TADIXS  may  consist  of  more  than  one 
communications  ‘circuit  and/or  bearer  service, 
or  more  than  one  TADIXS  may  use  the  same 
communications  service  and/or  bearer  service, 
and  therefore  it  is  not  correct  to  map  TADIXS 
into  fixed  communications  circuits  and  bearer 
services.  TADIXS,  therefore,  take  shape  in  the 
decision  about  where  to  send  the  data  and  how  to 
display  it.  Simply  put,  Copemican  TADIXS 
manifest  themselves  at  destinations —  they  exist 
at  the  CCC  and  at  the  TCC  but  not  en  route  to 
either.  The  data  bound  for  one  TADIXS  may  be 
mixed  among  data  bound  for  another. 

The  physical  appearance  of  a  TADIXS 
boundary  is  a  communications  software  seg¬ 
ment  that  sends  and  receives  data  to  others 
holding  the  same  segment  and  a  mission-spe¬ 
cific  HMI  on  the  FASTT,  which  provides  the 
context  in  which  the  data  becomes  operational 
information. 

Finally,  the  sixth  decision  is  to  select  the 
communications  resources  (communications 
circuits  and  bearer  services)  over  which  the 
TADIXS  virtual  information  networks  will  be 
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transmitted  and  received.  That  selection  is  made  In  the  next  chapter,  we  will  discuss  the 

in  accord  with  the  Communications  Support  nature  and  the  requirements  for  the  first  Coper- 
System  Communications  Resource  Manager.  nican  pillar,  the  GLOBIXS. 
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SUMMARY  p 

ashore  to  support  the  forces  afloat  They  ate  configured  on  a  theater  or” worldwide  basis  and  are  constructed  to  transport 
standardize,  and  concentrate  shore-based  sensor,  analytic,  command  support  administrative;  and  other  data  for  further 
:  passage  to  commanders  afloat  GLOBIXS  will  use  current  and  planned  a>mmon-usercommunication  systems,  such  as 

:  Sill  GLOBIXS  reflect  the  belief  that  the  post-CoId  War  operating  environment  wili  be  far  more  data-intensrve  and 
require  far  more  technological  agility  in  obtaining,  handling,  and  transmitting  data  than  during  the  Cold  War.  The 
development  of  inodem  communications  backbones  ashore:  over  the  last  16  years,  both  within  industry  and  within  die  | 
jOepa^entpf  L>efense  has ^hicrbasetl  our  nation^  comnitini<|ttii^^ 

inodem  systems  enable  subscribers  to  pass  large  volumes  of  data  hundreds  of  times  fastCT  than  die  existing  tMfetype  Circuits 
resident  today  iii  most  Navy  communications  centers. '-if.;' 

A  second  and  equally  critical  development  over  the  last  10  years  has  been  the  growth  bf  small  computers,  both 
■pOi^iial  computers  (PCS|: aiiii 

American  workers.  The  developmental  trends  in  computing  Over  the 
standards  and  to  open  systems  architectures. 

These  two  developments,  theestablishmentof ‘‘information  highways”  and  themovement  towards  open  systems 
architectures,  make  possible  the  aggregation  of  many  shore-based  commands—  both  Navy  arid  non-Navy ;  into  powerful 
•  networks  of  “communities  of  common  interests."  These  virtual;  shore-based  nee;  called  GLOBIXS,  are  defined  npt  by  ; 
physical  boundaries,  but  by  DCS  addresses  and  a  common  software  “veneer.”  Thus,  it  becomes,  possible  to  constfuct  a 
global  Signals  Intelligence  (SIGINT)  or  a  High  Command  net  with  little  investment  in  communications  infirash^ctuie; 
using  standardized  hardware  “engines,”  and,  to  make  the  conceptual  leap  from  data  to  information  via  the  software 
“veneer,”  ^  •’  ■'•••'  v':  . :  ^  '':- 

GLOBIXS  will  be  constructed  like  interstate  highways—  they  are  limited-access,  high-speed,  and  highly 
concentrated.  Additionally,  like  interstate  highways,  they  have  connections  among  each  other  so  that  traffic  may  be 
shunted  (as  provided,  by  doctrine)  across  several  GLOBIXS  as  well  as  to  the  operating  forces  through  a  consolidated 
Commander  in  Chiefs  (CINQ  Command  Complex  (CCC),  the  second  pillar  of  Copernicus. 

As  we  saw  in  Chapter  3,  in  today’s  architecture,  33,000  commands  ashore  can  send  messages  to  sea  at  the  whim 
and  timing  of  the  sender,  not  the  receiver.  The  receiver — the  operator—  is  thus  inundated  and  robbed  of  critical 
communications  capacity.  Tomorrow,  under  Copernicus,  GLOBIXS,  intersected  and  managed  through  the  CCC,  will 
form  a  limited-access  information  system  that  can  be  controlled  and  configured  by  the  operator,  not  the  sender. 

Through  GLOBIXS ,  operational  priorities  can  be  set  and  managed  by  the  operator  using  doctrine  established  to 
manage  the  system.  One  Composite  Warfare  Commander  (CWC)  may  desire  to  be  connected  to  one  set  of  GLOBIXS 
nodes  while  another  CWC  may  want  to  talk  to  a  different  set  Technologically,  this  is  a  matter  of  addressing.  Doctrinally, 
this  will  be  achieved  through  the  development  of  a  Naval  Warfare  Publication  (NWP)  for  Copernicus  management. 
Through  the  matrix  of  GLOBIXS  information  options  introduced  in  the  previous  chapter,  the  CW C  will  select  his  CJNC 
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Command  Complex  Watch  and  activate  the  GLOBIXS  nodes  he  wants  in  the  information  cases  desired  to  reflect  the 
command  and  control  decisions  he  has  made  for  the  mission. 

The  number  and  nature  of  GLGBIXS  is  intended  to  be  dynamic,  so  the  architecture  can  support  the  command 
structure  over  the  next  5decades ,  not  merely  thenext  5  years.  For  example,  some  CINCs  may  desire  to  construct  a  logistics, 
weather,  planning,  and/or  contingency  GLOBIXS.  Doing  so  simply  means  developing  a  software  veneer  for  the  common 
hardware  “engines”  envisioned  as  Copernicus  building  blocks.  We  also  can  envision  temporary;  contingency  GLOBIXS 
as  well  as  the  major,  standing  GLOBIXS. 

Theeight  standing  GLOBIXS  currently  defined  are  joint  both  in  character  and  by  definition  because  they  reflect 
:  i  Five  of  the  eight  GiL^lX&are  operationally  oriented  and  contain 

the  major  sensor  and  analytic  nodes,  boih  Navy  and  national;  SIGINT  GLOBIXS;  Anti-Submarine  Warfare  (ASW) 
GLOBIXS  ;SpaceandEIectronic  Warfare  (SEW)  GLOBIXS;  Imagery  GLOBIXS;  ahdDatabase  Management  GLOBIXS: 
#:  sixth>  the  Cohimand  GLOBIXS;  (e^^video ,  mli^onferCTC.ing;,^voice;  facsimile^  narrative)  net, 

^^^g  war  cdtnmands  (i.evnumlwed  fleets.  Fleet  Commander  in  Chiefs  {^TClNCsJ,  ccra^ 

GLOBIXS ani'  primarily  sbpp<^yeMnatiTOr  ^ 

ties  together  Navy  research  and  development  laboratories,  weapons  testing  facilities,  and  other  developmental  entities  for 

security  and  for  information  exchange.  Navy  Inform  ation  Exchange  Sys  tern  (NAVIXS),  will  be  the  Navy  implementation 
Of  the  Defense  Message  System  (DMS).  NAVIXS  is  the  main  textual  data  pathway  for  Navy,  and  until  true  multilevel 
security  is  achieved,  will  operate  separately  at  the  GENSER  and  Sensitive  Compartmented  Information  (SCI)  levels. 


DISCUSSION 

Global  Information  Exchange  Systems 
(GLOBIXS)  are  virtual  networks  that  link  the 
commands  and  activities  ashore  in  order  to  sup¬ 
port  the  forces  afloat  They  are  configured  on  a 
theater  or  worldwide  basis  and  are  constructed 
to  transport  standardize,  and  concentrate  shore- 
based  sensor,  analytic,  command  support  ad¬ 
ministrative  and  other  data  for  further  pas  sage  to 
commanders  afloat  GLOBIXS  will  use  current 
and  planned  common-user  communication  sys¬ 
tems  such  as  the  evolving  Defense  Communica¬ 
tion  System  (DCS)  or  FTS2000  depicted  in  (see 
fig.  4-1)  as  vehicles  for  network  communica¬ 
tion. 

This  chapter  explains  the  operational 
need  for  GLOBIXS,  how  they  are  technically 
possible,  defines  the  kinds  of  information  func¬ 
tions  and  services  to  be  transported,  and  defines 


the  initial  set  of  GLOBIXS  now  being  consid¬ 
ered  in  terms  of  their  user  communities  and 
information  functions  and  services. 

OPERATIONAL  NEED  FOR  GLOBIXS 

GLOBIXS  reflect  the  belief  that  the  post- 
Cold  War  operating  environment  will  be  far 
more  data-intensive  and  require  far  more  tech¬ 
nological  agility  in  obtaining,  handling,  and 
transmitting  data  than  during  the  Cold  War. 

The  development  of  modem  communi¬ 
cations  backbones  ashore  over  the  last  10  years, 
both  within  industry  and  within  DOD,  has  in¬ 
creased  our  national  communications  infrastruc¬ 
ture  by  orders  of  magnitude.  The  DCS  will 
enable  subscribers  to  pass  large  volumes  of 
information  many  times  faster  than  the  existing 
teletype  circuits  resident  today  in  most  Navy 
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\  Figure  4>t  Bearer  Services  Evolution 


communications  centers.  Moreover,  the  DCS  is 
but  one  manifestation  of  an  increasingly  com¬ 
plex  nationwide  data  infrastructure  that  will  be 
as  critical  to  American  industry  and  Govern¬ 
ment  for  the  next  century  as  the  physical  infra¬ 
structure  of  roads,  telephones,  and  power  plants 
was  in  the  last  Fiber  optic  cable,  with  the 
promise  of  massive  data  transfer,  is  circling  the 
globe. 

A  second  and  equally  critical  develop¬ 
ment  over  the  last  10  years  has  been  the  growth 
of  small  computers,  both  PCs  and  workstations. 
The  computing  power  that  made  it  possible  for 
the  Apollo  program  to  put  a  man  on  the  moon  is 
now  on  the  desks  of  the  American  workers.  The 
developmental  trends  in  computing  over  the  last 
decade  have  led  to  more  clearly  visible  industry 


standards  and  to  open  systems  architectures  (see 
accompanying  boxed  text  4-1  and  boxed  figure 
4B-1.1),  signalling  relief  to  the  necessity  to 
invest  in  unique  systems. 

These  two  developments,  the  establish¬ 
ment  of  “information  highways”  and  the  move¬ 
ment  towards  open  systems  architectures,  make 
possible  the  aggregation  of  many  shore-based 
commands —  both  Navy  and  non-Navy  into 
powerful  networks  of  “communities  of  common 
interests.”  These  virtual,  shore-based  nets,  called 
GLOBIXS,  are  defined  not  by  physical  bound¬ 
aries,  but  by  DCS  addresses  and  a  common 
software  “veneer.”  Thus,  it  becomes  possible  to 
construct  a  global  Signals  Intelligence  (SIGINT) 
or  a  High  Command  net  with  little  investment  in 
communications  infrastructure  using  standard- 
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Boxed  Text  4-1:  Open  Systems  Interconnection  (OS I) 


f  Iff ; :  fo  the  WOrld  OfCOmpOterS,  pTOtOCOlS  are  vital  tO 
coramun^  may 

have  no  other  commonality  to  exchange  ideas  with  a  ' i 
tninimumcf  a^usiotund  inismterpre^ 
layered  protocols  does  not  antqirn^ 
systems  interconnecticm.  I^ji^pt^  : 

tectures  designed  since  the  1960s  are  based  on  layered  I 
protocols,  yet  the  problems  of  incompatible  protocols 
still  plagues  industry.  •  • '  :/f.  f  vl-f  I  ■  f 

Since  a  layered : 

provide  open  sy^ms  when  djere  areiconuhon  defirii-  ; 
tions  of  the  protocols  at  each  layer,  the  first  step  toward 
making  an  open  system  possible  is  the  definition  of 
layers.  In  thearea  of  international  standards,  the  standard 
seven-layered  network  architecture  is  defined  by  the 
Open  Systems  Interconnection  (OSI)  Reference  Model. 
The  layering  definitions  provided  by  this  model  have 
been  usedas  a  framework for  defining  standard  protocols 
that  can  be  used  to  implement  open  systems  networking. 

■ '  The  OSI  Reference  Model  alone  is  not  suffi¬ 
cient  to  provide  general  pu^se  cpnnecdyUy;  It  defines  ; 
only  a  framework  for  a  layercd:archi|ecferiii  it  does  not 
provide  the  protocolspecifications  necessary  to  imple¬ 
ment  a  networking  capability.  ” 

%  ■■  ■  Ckivemnent  Ophh  Systems  Interconnect  : 

tion  Profile  (GOSIP)  (see  boxed  figure  4B-i^  1)  repre-  III 
sents  a  profile based  oh  available  stable  international 
|tandards.  A  profile  specifies  the  e^i  protocols  to  be 
implemented,  including  features  to  be  included,  feature 
not  to  be  used,  and  the  “correct”  interpretation  of  ambi¬ 
guities  in  the  international  standards.  The  GOSIP  sped-  ' 
fication  of  protocols  is  based  on  agreements  reached  by 
vendors  and  users  of  computer  networks  participating  in 
the  National  InstituteofStandardsandTechnology  (NIST) 
OSI  Workshops.  Approval  for  GOSIP  was  published  in 
Federal  Information  Processing  Standard  (FIPS)  Num¬ 
ber  146  onT5  August  1988.  GOSIP  is  to  be  used  by  all 
Federal  Government  agencies  when  acquiring  computer 
netwcKk  products,  services,  and  communications  sys¬ 
tems.  Implementation  has  been  mandatory  since  August 
1990. 


Widespread  use  of  GOSIP  will  provide  several 
impoitantbeni^ts:.:vH.:i:: 

lip  Low^ir  hardware  costs  for  distributedcomputer 
•  systems;  " 

*  Lower  software  development  costs  fix  net¬ 
work-related  functionsjand 

4:^  =  >v': ;  * :  J .  IrjOWlNr  trmriihg  c^sts  ifor  ^  persoimel  and 

..  users. 

the  main  featuresof  GOSIP  l  were  the  ability 
|l!tb  ;send  and  receive  E-Mail  using  Message  Handling 
System  (MHS)  X.400;  and  the  ability  to  access  and 
transfer  files  using  File  Transfer,  Access,  and  Manage¬ 
ment  (FTAM).  Fbr  network  technology,  GOSIP  sup¬ 
ports  the  International  Electrical,  Electronics  and  Engi¬ 
neers  (IEEE)  Standard  802.3  (Elhemet)  over  baseband 
or  broadband,  802.4  (Token  Bus)  over  10  mbps  broad¬ 
band  or  5  mbps  carrier  band,  802.5  (Token  Ring),  and 
X.25  packet  switching  access.  In  addition,  GOSIP 
jispecifies  Connectionless  Netwcuic  Ptotocdl  (GLNP)  to 
provide  reliable  end-to-end  data  paths  between  net- 
wo^aliowngseveralllANstopperate^  GOSIP 
2added  protocols  for  Virtual  Terminal  (VT)appIications 
aniathe  IntBjgrmed  Searyices  Digital  Netwbric  (ISDN) 
protocols  to  support  a  wide  rangeofvoiceand  non-voice 
appUcbions  in  one  network*  Future  versions  of  GOSDP 
;  will  include: 

ElAMexpansion  to  ineotpaate  raorecapabili- 
ties  and  document  types; 

*  X.400-1988  MHS; 

*  ’  ;#irecbry  Services;: 

*  Network  Management; 

*  Transaction  Processing  (TP); 

*  Electronic  Data  Interchange  (EDI); 

*  Intermediate  System-to-Intermediate  System 

^  (IS-IS);  : 

*  Transport  Protocol  Class  2  (TP2); 

*  Fiber  Distributed  Data  Interface  (FDDI)  me¬ 
dium  access  control.  Physical  Layer  protocol, 
and  physical  medium  dependent;  and 

:  ■  •  Security  protocols. 
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While  GOSIP  may  be  applicable  to  GLOBIXS, 
there  ate  currently  unresolved  differences  when  GOSIP 
is  applied  to  the  tactical  RF  communications  environ¬ 


mentsupporting  voice  and  real-time  tactical  information 
networks. 


I . I  Newin  GOSIP  Version  2 

I . T  : 
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Boxed  Figure  4B-1.1.  Framework  for  GOSIP 
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ized  hardware  “engines”,  and  to  make  the  con¬ 
ceptual  leap  from  data  to  information  via  the 
software  “veneer.” 

The  intention  is  to  allow  the  Com¬ 
mander  in  Chief  U.S.  Pacific  Command 
(USCINCPAC)  to  tap  into  the  Command 
GLOBIXS  to  communicate  with  the  Commander 
in  Chief  U.S.  Pacific  Fleet  (CINCPACFLT) 
whether  the  former  is  in  CampH.M.  Smitfrxa- 
TAD  in  Australia.  Moreover,  such  nets,  through 
the  GLOB  IXS/T ADIXS  concept,  allow  a 
SIGINT  analyst  at  the  National  Security  Agency 
(NSA)  to  assist  a  SIGINT  watchstander  afloat 
without  dedicating  precious  satellite  communi¬ 
cations  capacity  end-to-end  as  we  must  do  to¬ 
day. 

Thus,  the  first  pillar  of  the  Copernicus 
Architecture  consists  of  the  GLOBIXS —  the 
ashore  nets.  The  GLOBIXS  will  be  a  series  of 
virtual  sensor  and  analytic  nets  that  will  provide 
information  management  and  information  con¬ 
centration  by  acting  as  the  shore  gateways  for 
specific  reports  to  sea. 

GLOBIXS  will  be  constructed  like  inter¬ 
state  highways —  they  are  limited-access,  high¬ 
speed,  and  highly  concentrated.  Additionally, 
like  interstate  highways,  they  have  connections 
among  each  other  so  that  traffic  may  be  shunted 
(as  provided  by  doctrine)  across  several 
GLOBIXS  as  well  as  to  the  operating  forces 
through  a  consolidated  CINC  Command  Com¬ 
plex  (CCC),  the  second  pillar  of  Copernicus. 


As  we  saw  in  Chapter2,  in  today’s  archi¬ 
tecture,  33,000 commands  ashore  can  send  mes¬ 
sages  to  sea  at  the  whim  and  timing  of  the  sender, 
not  the  receiver.  The  receiver — the  operator — 
is  thus  inundated  and  robbed  of  critical  commu¬ 
nications  capacity.  Tomorrow,  under  Copernicus, 
GLOBIXS,  intersected  and  managed  through 
the  CCC,  will  form  a  limited-access  information 
system  that  can  be  controlled  and  configured  by 
-  the  operator,  not  the  sender.  * 

Through  GLOBIXS,  operational  priori¬ 
ties  can  be  set  and  managed  through  doctrine. 
One  CWC  at  a  particular  time  may  desire  to  be 
connected  to  one  set  of  GLOBIXS  nodes  while 
another  CWC  may  want  to  talk  to  a  different  set. 
Technologically,  this  is  a  matter  of  addressing. 
Doctrinally,  this  will  be  achieved  through  the 
development  of  a  Naval  Warfare  Publication 
(NWP)  for  Copernicus  management  Through 
the  matrix  of  GLOBIXS  information  options 
introduced  in  the  previous  chapter,  the  CWC 
will  select  his  CCC  Watch  and  activate  the 
GLOBIXS  nodes  he  wants  in  the  information 
cases  desired  to  reflect  the  command  and  control 
decisions  he  has  made  for  the  mission. 

Of  course,  all  commanders  will  require  a 
certain  core  of  information  from  shore-based 
analytic  nodes  and  sensor  sites.  However,  com¬ 
manders  who  want  large  volumes  of  one  type  of 
data  but  not  another  or  who  want  greater  or 
lesser  diversification  of  data  among  the  CWC 
subordinates  can  tailor  their  information  re¬ 
ceipts  from  the  GLOBIXS  matrices  accordingly. 
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In  addition  to  providing  for  information 
management  and  concentration,  GLOBIXS  will 
reflect  a  dramatic  change  in  information  format. 
Most  GLOBIXS  will  be  characterized  princi¬ 
pally  by  voice,  sensor  location  reports  in  digital 
format  through  "trans-sanitization"  (see  boxed 
text  4-2),  video,  imaging  and  data  files,  although 
OPNOTE  traffic  will  be  significant  NAVIXS, 
the  Navy  implementation  of  the  DMS  will  carry 
traditional  narrative  messages.  „ 

The  number  and  nature  of  GLOBIXS  is 
intended  to  be  dynamic,  in  order  that  the  archi¬ 
tecture  may  support  the  command  structure  over 
the  next  5  decades,  not  merely  the  next  5  years. 
For  example,  some  CINCs  may  desire  to  con¬ 
struct  a  logistics,  weather,  planning,  and/or  con¬ 
tingency  GLOBIXS.  Doing  so  simply  means 
developing  a  software  veneer  for  the  common 
hardware  “engines”  envisioned  as  Copernicus 
building  blocks.  We  can  also  envision  tempo¬ 
rary,  contingency  GLOBIXS  as  well  as  the 
major,  standing  GLOBIXS. 

The  eight  standing  GLOBIXS  are  joint 
both  in  character  and  by  definition  because  they 
reflect  the  aggregation  of  communities  of  inter¬ 
est  DOD-wide.  Five  of  the  eight  GLOBIXS  are 
operationally  oriented  and  contain  the  major 
sensor  and  analytic  nodes,  both  Navy  and  na¬ 
tional.  They  are: 

•  Signals  Intelligence  (SIGINT)  GLOBIXS; 

•  Anti-Submarine  Warfare  (ASW)  GLOBIXS; 

•  SpaceandElectronic Warfare  (SEW)GLOBIXS; 

•  Imagery  GLOBIXS;  and 

•  Data  base  Management  GLOBIXS. 


A  sixth  is  a  multimedia  (e.g.,  video¬ 
teleconferencing,  voice,  facsimile,  narrative)  net, 
connecting  major  commands  (i.e.,  numbered 
fleets,  FLTCINCs,  component  commanders,  JTF 
commanders,  USCINCs): 

•  Command  GLOBIXS 

The  seventh  and  eighth  standing 
GLQBIXS< -primarily  are  supportive  in  nature. 
They  include: 

•  RDIXS,  ties  together  Navy  laboratories,  weap¬ 
ons  testing  facilities,  and  other  developmental 
entitiesforsecurityandfor  infatuation  exchange; 
and 

•  NAVIXS,  as  previously  mentioned,  is  the  Navy 
implementation  of  the  DMS.  Until  true  multi¬ 
level  security  is  achieved,  it  will  operate  sepa¬ 
rately  at  the  GENSER  and  SCI  levels. 

WHAT  IS  A  GLOBIXS? 

GLOBIXS  can  be  best  described  in  a 
layered  concept,  such  as  that  shown  in  figure 
4-2.  We  have  characterized  them  already  by 
mission,  defining  the  eight  currently  proposed 
GLOBIXS  above.  In  the  remaining  sections  of 
the  chapter,  we  will  look  at  other  characteristics 
of  GLOBIXS,  including  the  physical  makeup  of 
a  GLOBIXS  using  the  Command  GLOBIXS  as 
an  example.  We  will  then  look  at  the 
subscribership  and  communications  services  to 
see  how  GLOBIXS  can  improve  operations  and 
examine  their  functions. 
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Boxed  Text  4-2."Trans-sanitization’'  and  the  Copernicus  Common  Format 


Moving  away  from  the:  message as an  opera¬ 
tional  format  is  a  critical  requirement  for  all  of  the 
reasons  discussed  in  Chapter  2  of  this  document  As  a 
practical  matter,  we  must  move  into  cnirnew  architecture 
gradually  over  a  Six  Year  Defense  Plan  (SYDP)  (as  a 
minimum)  and  be  able  to  use  as  much  of  our  existing 
hardviire  and  &fiware  ie^  :- 

is:  completed. 

Although  thetask  sounds  monumental,  in  real¬ 
ity,  it  is  achievable;  What  is  required  is  Construction  of 
a  building  block  we  call  a  “trans-sanitizer*11  afteritstwcr- 
functions;  transliterating  many  existing  character-ori¬ 
ented  message  formats  into  a  common  binary  format 
{cialfed:  the  €$pemic^  format). 


that  it  can  be  received  over  one  communications  pathway 
b)f several  UseiS -wtifln^  ; 

By  placing  the  "trans-sanitisEegr",:  which  is  envi- . : 
sioned  as  a  GOTS  software  package  overlaid  on  the 
'  FASTT,  ’  between  existing  equipment  both  on  the; 
GLOBDCS  end  and  the  TADDCS  end,  the  existing  char¬ 
acter  messagestan  uansfiteratedintoah  efficient,  and 
;  common,  binary  format.  See  accompanying  figures : 

1  One  form  of  a  Trans-sanitizer‘*  currently  in  development  is 
RADIANT  Mercury,  developed  under  the  auspices  of  Navy 
Tactical  Exploitation  cif  National  Capabilities  (IENCAE); 


SO  aad  CENSE*  EXISTING  FORMATS 
(U5.  Menage  Text,  Format,  OIH  Gold, 
HPDF  Report*,  SOSUS  Report*.  TACEUNT, 
TRAP/TRB  Format  Ooan  SaretOeno* 


: ;  xV;:’56ftware  ff:;;::: 


liSllll  Prom  an  operational  standpoint,  COFCOM  for- 
mats  provide  fortheexchangeofalilocationaldataamong 

versions"  in  the  FAiSTTs  for  different  data  recipients. 
Thus,  while  the  data  from  the  sensor  gateway  on  DDN 
may  be  SCI,  it  can  be  read  by  consumers  bpom  SClio  non- 
SCI  copsumeis:  pn  a  yjie  ■ 

implications  are  several: 

-  "  «  -  Sensor  data  &dm  any  sfcftsdr,  non-organic  or 
organic,  can  be  displayed  alongside  data,  fiom 
another  sensor  because  all  such  data  is  in  a 
common  format; 

•  Because  all  sensor  data  is  in  the  same  format, 

; :  contact  inqxxrts  become  ma^eabld  & 

sor  datum  is  in  the  same  format; 

•  Because  data  management  becomes  possible- 
thatis,  the  sensor  dataacqoired  on  the  2500 ships 

Jit the  Mediterranean  discussed  tit  Chapter  2 
yield  a  much  more  realistic  number  of  contact 
rqxhts-thedelegationofwarfaretasksachieved 

doctrinally  of  warfare  tasks  is  achieved  technol¬ 
ogy  as  well.  The  result  is  to  greatly  leverage  the 
CWC  delegation,  which  in  turn  will  lead  us  to 
better  tactics  and  beaerdoctritie; •' k: '  -Y.> 


«fa.B 


DCS  Bearer  Service 


jg'psa 

r 

L 

1  TO 

i 

Boxed  Figure  4B-2.1.  Trans-sanitization 
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Boxed  Figure  4B-2.2.  Sensor  Report  Trans-sanitization 
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GLOBIXS  BUILDING  BLOCKS 


The  technological  manifestation  of 
GLOBIXS  are  derived  from  four  types  of  Co¬ 
pernicus  building  blocks  (see  fig.  4-3)  that  will 
be  discussed  in  considerable  detail  in  chapter  8: 

•  Network  services,  which  for  GLOBIXS  are  im¬ 
posed  over  both  the  DOD  DCS  and  over  com¬ 
mercial  bearer  services; 

•  Hardware,  which  will  be  finite  in  number.  Most 
hardware  building  blocks  for  GLOBIXS  exist 
today;  however,  selecting  a  standard  building 
block  from  the  many  duplicative  stove-pipe  pro¬ 
grams  will  be  necessary  (see  chaps.  9  and  10); 

•  Operating  systems,  which  will  be  commercial- 
off-the-shelf  (COTS)  in  origin;  and 

•  Software,  whichwilllargelybeCOTS;however, 
all  software  that  is  Government-unique  will  be 
written  in  Ada. 


Using  these  four  components,  it  is  pos¬ 
sible  to  construct  a  model  of  a  less  conceptual 
GLOBIXS  and  add  it  to  the  information  product 
matrix  (i.e.,  cases  and  formats  of  data)  shown  in 
Chapter  3  and  repeated  in  figure  4-4.  Of  the 
eight  GLOBIXS  described,  all  are  constructed 
identically;  the  difference  among  them  will  be 
subscribership  and  product  Using  the  Com¬ 
mand  Model,  we  will  examine  briefly  the  con¬ 
struction  of  a  GLOBIXS.  In  the  section  follow¬ 
ing"  thisr  we~  wiH'  examine  the  purpose  of  a 
GLOBIXS  to  see  what  a  GLOBIXS  does. 


THE  COMMAND  MODEL 

Although  the  Command  GLOBIXS  in¬ 
terconnect  the  National  Command  Authorities 
(NCA)  and  the  numbered  fleet  commanders2, 
there  likely  will  be  split  operational  claimancy 
of  the  GLOBIXS  among  CIN CL ANTFLT, 
CINCPACFLT,  and  CINCUSNAVEUR  along 
the  existing  theater  lines3.  Programmatic 
claimancy  and  architectural  oversight  will  be 
assigned  to  the  Naval  Computers  and  Telecom¬ 
munications  Command  (NCTC),  who  will  inter¬ 
face  with  the  Defense  Communications  Agency 
(DCA). 


Command  GLOBIXS  Network  Services 

Subscribership  on  the  GLOBIXS  would 
vary  by  theater  and  reflect  the  CINCs  direction. 

2  And,  through  the  Command  TADIXS,  to  the  tactical 
commander. 

If  Copernicus  is  adopted  by  the  USCINCs,  those  commanders 
would  be  expected  to  be  the  Command  GLOBIXS  claimants. 
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Functional  Architecture 
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Figure  4-4.  Communications  Services:  Precedence  and  Format 
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The  GLOB  IX  S  command  networks  are 
intended  to  directly  support  the  command  au¬ 
thorities.  Therefore,  of  the  eight  formats  shown 
in  figure  4-4,  it  is  anticipated  that  those  used  by 
the  Command  GLOBIXS  will  be  voice, 
OPNOTE,  data  files,  imagery,  and  video  tele¬ 
conferencing.  (Architecturally,  all  services  can 
be  made  available,  however.)  Messaging  also 
will  be  available  on  the  Command  terminals; 
however,  such  messages  will  be  released  and 
passed,  not  over  the  Command  GLOBIXS,  but 
through  NAVIXS,  and  routed  onto  the  Com¬ 
mand  terminals.  Transmission  path  will  be 
transparent  to  the  user4. 

Bearer  services  for  the  GLOBIXS  would 
be  selected  by  Naval  Computer  and  Telecom¬ 
munications  Command  from  those  shown  in 
figure  4-1,  using  cost,  availability,  suitability 
and  other  attributes  for  selection. 

In  this  way,  we  can  define  the  Command 
GLOBIXS  model  both  in  terms  of  subscribership 
and  in  information  type,  the  latter  of  which  is 
shown  in  figure  4-5 .  Thus,  from  the  standpoint 
of  the  information  network  and  communications 
services,  the  Command  GLOBIXS  is  a  network 
imposed  over  DCS  (or  commercial)  bearer  ser¬ 
vices  that  ties  together  the  high  command  infra¬ 
structure  ashore  (and  via  the  TADIXS,  afloat) 

4  It  is  important  to  recognize  this  point  GLOBIXS  are  intended 
to  decant  information  into  layers.  A  command  GLOBIXS 
terminal,  while  it  will  have  the  capability  to  create  and  receive 
traditional  messages,  is  intended  to  place  one  commander  in 
direct  contact  with  another.  A  NAVIXS  terminal,  on  the  other 
hand,  would  be  the  normal  position  to  send  and  receive  mes¬ 
sages.  The  use  of  the  word  "terminal”  here  is  intended  to  convey 
a  position—  that  is,  a  second  Fleet  All-Source  Tactical  Terminal 
(FASTT),  not  a  unique  hardware  and  software  engine  for  Com¬ 
mand  and  another  for  NAVIXS. 


Command  GLOBIXS  (From  Figure  4-2) 

•  Voice  •  Imagery  1  and  2 

•  OPN 1  and  2  •  Video 

•  Data  File  1  and  2 

Figure  4-5.  Command  GLOBIXS 
Information 

using  immediate  and  near-immediate  priority 
services:  "voice,  OPNOTE,  data  files,  imagery 
and  videoteleconferencing. 

Command  GLOBIXS  Hardware 

As  we  change  perspective  from  network 
services  to  hardware,  GLOBIXS  construction 
remains  straightforward.  At  each  command 
node,  the  Command  GLOBIXS  “positions” 
would  include  a  Secure  Telephone  Unit  (STU- 
HI)  terminal  and  a  FASTT,  configured  for 
videoteleconferencing.  (However,  it  is  recog¬ 
nized  that  some  command  nodes  will  utilize  full 
videoteleconferencing  studios,  while  others  will 
need  only  the  video-configured  FASTT  termi¬ 
nal.)  A  file  server  may  be  necessary  at  large 
command  nodes  to  support  the  Command 
GLOBIXS.  This  server,  however,  will  likely  be 
a  local  area  network  (LAN)  file  server,  not  a 
distinct  Command  GLOBIXS  server. 

Moving  from  the  command  position  to 
the  bearer  service,  the  position  will  be  served  by 
a  communications  processor,  which  may  be  a 
stand-alone  processor  or  a  card  in  the  FASTT  at 
small  nodes. 
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Hardware  from  the  processor  to  the  bearer 
service  will  depend  on  that  service  as  shown  in 
figure  4-6.  It  is  desirable  ultimately  that  cryp¬ 
tography  be  embedded  in  the  terminal. 

Software  Components 

Software  segments  for  the  Command 
GLOB1XS  will  be  modular,basedon.open.  ays= — „ 
terns  standards.  Figure  4-7  shows  a  FASTT 
terminal  configured  for  the  Command  position. 

It  represents  the  simplest  case,  one  in  which  one 
position  is  used  in  the  absence  of  a  larger,  more 
complex  series  of  positions  such  as  that  envi¬ 
sioned  in  a  large  command  center. 


SENSOR  GLOBIXS:  WHAT  ARE  GLOBIXS 
FUNCTIONS? 

The  sensorGLOBIXS— SIGINT,  ASW, 
Imagery,  and  SEW —  are  more  complex  techno¬ 
logically  than  the  Command  GLOBIXS,  both  in 
terms  of  type  and  quantity  of  information.  Both 
for  simplification  and  for  classification  pur¬ 
poses,  we  will  discuss  these  GLOBIXS  gener¬ 
ally. to-describe  their  functions. 

The  sensor  GLOBIXS  will  be  composed 
of  five  types  of  subscribers,  some  of  which  are 
co-located,  others  of  which  are  not  (see  fig.  4-8): 

•  Sensor  nodes; 

•  Regional  analytic  nodes; 

•  Non-Navy  nodes,  including  allied,  that  may  fall 
into  either  category; 


Figure  4-6.  GLOBIXS  Connectivity  from  NODE  to  CCC 
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•  Theater  or  national  analytic  nodes;  and  •  To  provide  the  CCC  with  a  common  formatted 

graphics  and  OPNOTE  product  via  a  standard 

•  The  “anchor”  desk  connected  to  the  CCC  MAN.  analyst  FASTT  station  with  tailored  software  for 

each  GLOBIXS. 


GLOBIXS  Model  Missions 

The  sensor  GLOBIXS  have  distinct  mis¬ 
sions  from  those  of  the  RDIXS,  NAVIXS,  Data 
base,  and  Command  GLOBIXS.  The  sensor 
GLOBIXS  provide  locational  and-anaiy  tic  ' 
to  the  tactical  commander  and,  importantly,  ex¬ 
cept  for  the  direct  targeting  TADIXS  (which  are 
not  discussed  in  this  document  for  classification 
purposes)  are  the  sole  gateway  for  that  informa¬ 
tion  to  the  commander.  That  is,  as  a  matter  of 
doctrine,  sensor  traffic  will  not  be  duplicated  on 
NAVIXS  and  the  SIGINT  GLOBIXS,  although 
architecturally  for  redundancy  the  CCC  techni¬ 
cally  can  shunt  any  traffic  over  any  GLOBIXS  if 
necessary.  The  functions  of  the  SIGINT,  ASW, 
Imagery,  and  SEW  GLOBIXS  will  be; 

•  Within  the  warfare  mission  area,  to  provide  the 
Navy  share-based  analytic  conduit  from  the  CCC 
to  the  Navy  and  national  sensors; 

•  Collection  management  through  the  CCC  to 
maximize  the  national  sensors  for  tactical  use; 

■  From  the  sensor  and  other  data  inputs,  to  provide 
technical  analytic  experience  andexpertise  within 
the  mission  area  that  is  not  available  afloat; 

•  To  develop  and  maintain  historical  and  regional 
data  bases  and  standardized  modeling,  analytic, 
and  decision  software  tools; 

•  To  provide  an  ashore  intersection  with  the  other 
Services,  DOD  agencies,  and  allies  within  the 
mission  area;  and 


The  operations  of  the  sensor  GLOBIXS 
are: 

•  To  collect  input  sensor  or  other  data  from  the 
source5; 

•  To  analyze  it  for  use  within  the  mission  area  the 
GLOBIXS  is  designed  to  support;  and 

•  To  disseminate  the  data  efficiently  in  a  standard 
format  to  the  CCC  for  dissemination  to  the  fleet 

How  the  Sensor  GLOBIXS  Help 

Theconstruction  of  the  sensor  GLOBIXS 
improves  current  operations  and  information 
management  several  ways.  First,  they  provide 
an  organizational  infrastructure  with  analysts 
and  data  bases  to  provide  a  structured  handoff 
between  Navy  and  other  agencies,  including  the 
other  Services,  law  enforcement  agencies,  and 
the  allies. 

Second,  the  technological  base  becomes 
standardized,  as  we  saw  in  the  Command 
GLOBIXS  model  above.  The  bearer  services 
are  common.  End  terminal  equipment  is  cen¬ 
trally  proscribed:  STU-lHs,  standard  secure  fac¬ 
similes,  and  FASTTs. 

Third,  because  of  prescribed  architec¬ 
ture,  the  technological  base  can  be  maintained 

5  Provided  that  the  source  does  not  already  disseminate  that  data 
through  the  direct  targeting  TADIXS. 
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through  Planned  Incremental  Modernization 
(PIM),  a  logistics  approach  to  OI  hardware  and 
software  that  provides  for  vendor  replacement 
of  components  as  they  reach  obsolescence  (see 
chaps.  9  and  10). 

Fourth,  by  prescribing  the  architecture 
up-echelon,  the  actual  development  of  analyti¬ 
cal  tools,  decision  software,  net  and  nodal  com¬ 
position  can  all  be  developed  down-echelon. 
Such  an  approach  has  two  distinct  advantages: 

•  It  provides  for  local  innovation,  which  is  critical 
to  the  development  of  flexible  doctrine,  and 
leverages  the  technological  sophistication  of 
Navy  men  and  women  today;  and 

•  From  a  programmatic  standpoint,  it  provides  a 
buffer  against  the  impending  cutbacks  risked  by 
centralized  procurementofenditems.  GLOBIXS 
subscribers  need  to  be  able  to  go  to  a  “catalog” 
and  order  the  standard  end-terminal  equipment 
to  service  the  nets  under  a  prescribed  “blue¬ 
print” 

Fifth,  using  FASTT  as  a  host,  we  can 
also  standardize  software  libraries  associated 
with  it  (e.g.,  word  processing,  data  bases,  imag¬ 
ery  processing,  digital  mapping,  correlation  al¬ 
gorithms),  while  allowing  great  innovation,  both 
in  Navy  and,  importantly,  in  industry,  to  con¬ 
tinue  in  software  library  applications  within  a 
specific  GLOBIXS.  The  use  of  FASTT  with  a 
veneer  of  application  software  puts  an  end  to  an 
era  of  end-to-end,  vendor-unique  systems. 

Sixth,  the  GLOBIXS  product  and  format 
going  to  the  CCC  can  be  standardized  for  multi- 
GLOBIXS  fusion  there  and  for  correlation  with 


the  TADIXS  product  inbound  to  the  CCC  from 
sea. 

Seventh,  by  using  X-windows,  the 
Copernicus  Common  sensor  reports  (COPCOM) 
(see  boxed  text  4-2),  and  an  OPNOTE  format 
like  the  Officer  in  Tactical  Command  Informa¬ 
tion  Exchange  System  (OTCIXS)  as  the  princi¬ 
pal  format  between  SIGINT,  SEW,  and  ASW 
GLOBIXS  nodes  and  the  analogous 
“warfighting”  TADIXS,  we  can  at  last  move 
away  from  the  formal  naval  message  as  the 
principal  operational  format.  We  are  on  the  road 
to  true  digital  information  exchange  instead  of 
paper  (or  electronic)  messages. 

GLOBIXS  DESCRIPTIONS  AND 
ENGINEERING  MODELS 

This  section  provides  brief  descriptions 
of  each  GLOBIXS.  Of  the  currently  identified 
eight  GLOBIXS,  two  SIGINT  and  ASW,  are 
considered  to  be  most  closely  structured  in  a 
manner  that  would  allow  for  expeditious  invest¬ 
ment  For  this  reason,  GLOBIXS  A  and  B  are 
presented  here  in  greater  detail  to  serve  as  engi¬ 
neering  models.  As  discussed  in  Chapter  10, 
each  of  the  GLOBIXS  will  be  the  subject  of 
considerable  effort  over  the  next  year  to  refine 
their  structures  and  requirements  as  individual 
operational  requirements.  The  definitions  be¬ 
low  are  intended  to  provide  the  reader  an  over¬ 
view  of  the  GLOBIXS. 
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GLOBIXS  A 

Signals  Intelligence  (SIGINT) 

GLOBIXS  A  supports  shore-based  sig¬ 
nals  intelligence  operations.  It  will  allow,  as 
required,  incorporation  of  allied  inputs  and  links 
the  Bullseye  Net  Control  Outstations,  the  Clas¬ 
sic  Wizard  Regional  Reporting  Centers,  NSA 
Special  Support  Activity,  the  National  Signals 
Operations  Center,  and  other  activities  design — — 
nated  by  Commander  Naval  Security  Group 
Command  and  the  FLTCINCs.  Additionally, 
special  data  bases  may  be  available  through  the 
DCS  backbones,  the  Defense  Special  Security 
Communications  System,  and  commercial  means 
in  addition  to  those  available  from  the  data  base 


6  Of  all  the  GLOBIXS,  the  data  base  GLOBIXS  poses  the  most 
serious  technical  challenges.  Multilevel  security.  Computer 
Security  (COMPUSEC),  and  information  robots-  software  rou¬ 
tines  that  seek  out  information  in  remote  data  bases-  are  all 
difficult  problems.  It  is  anticipated  that  until  the  arrival  of  these 
capabilities,  some  GLOBIXS  (e.g.,  the  sensor  GLOBIXS)  will 
operate  system  high.  Data  bases  for  security  reasons  will 
probably  reside  on  the  sensor  GLOBIXS  early  in  implementa¬ 
tion. 


GLOBIXS6.  Figure  4-9  shows  proposed 
GLOBIXS  responsibilities. 

The  GLOBIXS  A  CCC  interface  point 
will  be  the  communications  server,  anchored  by 
a  desk  on  the  CCC  to  be  designated  by  the 
FLTCINC —  perhaps  an  expanded  Cryptologic 
Support  Group  (CSG)  co-located  in  the  Joint 
Intelligence  Center  (JIC).  Data  base  support,  as 
.  determined-by-the  structure  of  the  GLOBIXS, 
will  be  developed  by  regional  analysis  centers. 
The  CCC  will  access  the  data  base  via  the 
network  to  support  the  planning  of  specific  op¬ 
erations. 

Inputs  in  the  form  of  existing  multiple 
formatted  messages  (as  determined  by  the  vari¬ 
ous  originators),  will  be  transliterated  into 
COPCOM,  and  information  forwarded  in  "trans- 
sanitized"  binary  format  beyond  the  CCC.  This 
will  be  accomplished  via  one  or  more  of  the 
force  operations  TADIXS,  as  selected  by  the 
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figure  4-9.  Proposed  GLOBIXS  Responsibilities 
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tactical  commander  selects  and  as  configured  by 
the  CCC. 


GLOBIXS  B 

Anti-Submarine  Warfare  (ASW) 

GLOBIXS  B  provides  the  ASW  “com¬ 
munities  of  interest”  with  the  capability  to  merge 
data  from  diverse  tactical  sensors  and  intelli¬ 
gence  sources,  to  collect  and  assess  that  data, 
and  then,  to  disseminate  it.  Transmission  links 
include  fiber  optic  systems,  microwave, 
SATCOM,  cable,  and  landlines  when  practical. 
GLOBIXS  B  will  be  structured  in  a  manner  that 
will  lend  itself  to  early  implementation. 

Like  all  the  sensor  GLOBIXS, 
subscribership  to  this  GLOBIXS  will  include 
the  five  types  of  nodes  presented  above.  ASW 
sensor  input  will  include  the  Integrated  Under¬ 
water  Surveillance  System,  andTAGOS,  as  well 
as  SEW  and  SIGINT  information  supplied 
through  cross-connects  atGLOBIXS  nodes  or  at 
the  CCC  (see  fig.  4-10).  In  early  implementa¬ 
tion,  input  data  formats  from  sensor  nodes  will 
be  in  existing  character-oriented  messages  and 
will  require  transliteration  into  the  COPCOM 
format  within  the  network.  The  Naval  Com¬ 
puter  and  Telecommunications  Area  Master  Sta¬ 
tions  (NCTAMS)  (forTAGOS  andSOSUS  con¬ 
nectivity)  will  serve  as  communications  gate¬ 
ways.  * 

Examples  of  GLOBIXS  B  nodes  will 
include  the  CCC  ASW  centers  and  the  Regional 
ASW  Command  Centers;  the  ASW  Operations 


Center;  the  Commander  Oceanographic  Sys¬ 
tems,  Atlantic  and  Pacific;  the  Naval  Ocean 
Processing  Facility;  the  Shore  ASW  Command 
Centers;  and  the  Submarine  Operations  Com¬ 
mand  Centers.  Each  node  will  have  the  broad 
categories  of  communications  services  shown  in 
figure  4-10. 

As  in  GLOBIXS  A,  information  from 
GLOBIXS  B_will-be  forwarded  via  the  force 
operations  TAD  DCS  as  they  are  configured  for 
ASW  purposes  by  the  CCC. 

GLOBIXS  C:  Space  and  Electronic  Warfare 

GLOBIXS  C  will  provide  focus  for  stra¬ 
tegic  and  tactical  SEW,  and  direct,  near-real¬ 
time  ocean  surveillance  information  of  airborne 
and  space-borne  targets.  It  will  operate  and 
develop  tactical  analytical  tools  to  interface  SEW 
TAD  DCS  with  GLOBIXS  C.  Connectivity  be¬ 
tween  nodes  will  be  via  the  DCS  or  commercial 
systems  into  the  CCC  communications  server. 

GLOBIXS  D:  Command 

As  we  have  seen,  GLOBIXS  D  ties  to¬ 
gether  the  FLTCINCs,  the  numbered  fleet  com¬ 
manders,  the  CCC,  and  designated  joint  and 
allied  commands.  War  plans,  operational  or¬ 
ders,  and  related  traffic  will  be  promulgated  via 
GLOBIXS  D.  The  GLOBIXS  D  network  will 
intersect  with  the  World  Wide  Military  Com¬ 
mand  and  Control  (WWMCCS)  Intercomputer 
Network  (WIN).  Media  services  provided  will 
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Figure  4-10.  ASW,  SIGINT  GLOBIXS  Interaction 


include  parallel  voice,  record,  and  video  (tele¬ 
conferencing  and  television).  Format  will  be 
media-dependent  GLOBIXS  D  connectivity 
will  be  by  the  DCS  or  commercial  service  as 
required. 

GLOBIXS  E  -  Imagery 

GLOBIXS  E  provides  a  means  for  con¬ 
trolled  flow  of  imagery  to  and  from  the  fleet  in 
support  of  strike,  amphibious,  and  other  tactical 
operations.  Potential  nodes  include  the  CCC, 
Defense  Intelligence  Agency,  Naval  Strike 
Warfare  Center,  NOIC,  Cruise  Missile  Support 
Activities,  and  elements  of  other  services.  Ac¬ 
cess  into  the  CCC  is  via  a  communications 
server  on  the  CCC  metropolitan  area  network 
(MAN).  The  imagery  GLOBIXS  anchor  will  be 
the  JIC.  GLOBIXS  E  connectivity  will  be  via 


the  DCS  or  commercial  networks  with  format 
being  a  functional  derivative  of  the  sensor/origi¬ 
nator. 


GLOBIXS  F:  Data  Base  Management 

GLOBIXS  F  provides  a  means  to  access 
data  base  files  for  their  movement  to  and  from 
sea.  GLOBIXS  F  nodes  may  include  the  CCC 
anchors,  JICs,  Fleet  Ocean  System  Intelligence 
Centers,  Fleet  Ocean  System  Intelligence  Fa¬ 
cilities,  the  Foreign  Technology  Directorate, 
Naval  Technical  Intelligence  Center,  DIA,CIA, 
NSA,  Naval  laboratories,  war  colleges,  the 
SYSCOM  community  and  others.  GLOBIXS  F 
will  be  anchored  at  a  Research  Center  to  be 
constructed  as  part  of  the  CCC  (see  chap.  5). 
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GLOBIXS  G:  Research  &  Development 

Information  Exchange  System  (RDIXS) 

GLOBIXS  G  provides  a  secure  means  to 
exchange  information  within  the  research  and 
development  (R&D)  communities  and  uses 
mode-appropriate  cryptographic  systems  aug¬ 
mented  by  parallel  STU-HIs.  GLOBIXS  G 
nodes  include  CNO,  the  various  SYSCOMs, 
Operational  Test  and  Evaluation  Force 
(OPTEVFOR),  and  the  Navy  laboratories  and 
test  ranges. 

GLOBIXS  H:  Navy  Information  Exchange 
System  (NAVIXS) 

GLOBIXS  H  provides  a  pathway  for  the 
narrative  messages.  NAVIXS  enables  practical 
elimination  of  hard  copy  traffic  with  Navy  ad¬ 
ministrative  offices  and  has  a  data  base  scheme 
predicated  on  sender,  receiver.  Standard  Subject 
Identification  Codes,  and  text  searches.  Mes¬ 
sage  originators  will  draft  and  release  messages 
at  their  desktop  for  secure  transport  to  the  mes¬ 
sage  recipients.  On-line  storage  and  update  of 
Navy  instructions  as  an  aid  to  Computer  Aided 
Logistics  System  and  paper  reduction  is  antici¬ 
pated. 

GLOBIXS  H  will  be  the  Navy  imple¬ 
mentation  of  the  DMS.  Connectivity  will  prima¬ 
rily  be  via  the  DCS  with  the  primary  controlling 
nodes  at  the  NCTAMS,  where  interfacing  with 
the  similar  NAVIXS  TAD IXS  will  occur. 
GLOBIXS  H  is  a  “special  case”  where  a  linear 


communications/information  flow  does  not  tran¬ 
sit  the  CCC  in  all  instances.  The  responsible 
claimant  for  this  GLOBIXS  is  COM- 
NAVCOMTELCOM. 

GLOBIXS  I -(N  +  l) 

GLOBIXS  I  -  (N  + 1)  is  a  generic  defini¬ 
tion  of  those  GLOBIXS  not  presently  addressed 
or  “designed.”  They  are  future  GLOBIXS  that 
will  satisfy  unique  requirements  not  availably 
through  the  eight  basic  GLOBIXS  previously 
defined.  The  GLOBIXS  I  -  (N  +  1)  structural 
composition  will  conform  to  the  pattern  or 
schema  established  by  the  eight  original 
GLOBIXS.  The  responsible  claimants  for  each 
additional  GLOBIXS  will  be  determined  by  user 
requirements. 


GROUPING  GLOBIXS  INTO 
COMMAND  CENTERS  AND  NODES 

All  of  the  GLOBIXS,  as  we  have  seen, 
are  carried  over  common  bearer  services,  use 
common  formats,  and  terminate  in  a  common 
terminal,  the  FASTT.  What,  then,  is  a  GLOBIXS 
node,  and  how  are  they  combined  to  form  a 
command  center?  In  the  next  chapter  we  will 
examine  the  CCC.  Before  we  do,  however,  let  us 
see  how  GLOBIXS  come  together.  Figure  4-1 1 
shows  a  diagram  of  DCS  or  commercial  bearer 
services  connecting  large  command  nodes.  In 
this  case,  we  have  included  the  United  King¬ 
dom,  Canada,  Australia,  and  New  Zealand  com¬ 
mand  nodes  as  well. 


The  Copernicus  Architecture  •  4-21 


Pacific  Command 


Nor&twood  :v. 


dNCUSNAVEUK 
nddrt  .  • 


MedCommand 

Comply 


Australian 


Command  Complex 


Command:  Complex 
Awddtfnd 


Figure  4-11.  GE.OBIXS  Bearer  Services  Connectivity  Among  Command  Centers 


On  the  command  center  end,  it  is  envi¬ 
sioned  that  the  long-haul  bearer  services  would 
terminate  in  a  MAN  such  as  the  proposed  Base 
Information  Transfer  System  (BITS).  Each  of 
the  commandnodes  indicated  in  the  figure  would 
implement  such  a  MAN. 

Atthe  GLOBIXS  node  end,  the  termina¬ 
tion  would  be  a  local  area  net,  served  by  a 
Copemican  building  block  communications  and 
file  server  analogous  to  that  on  the  MAN  (see 
chap.  9).  If  we  focus  on  one  area,  we  will  see 
that  most  of  the  five  types  of  GLOBIXS  nodes 
currently  have  access  to  the  bearer  services. 
What  is  necessary  is  to  define  the  GLOBIXS 
networks  on  the  existing  bearer  service  connec¬ 
tions.  To  do  so,  let  us  connect  three  nodes  into 


the  Norfolk  area  CCC,  implemented  through 
BITS. 

Logically*  the  first  sensor  node,  the 
Bullseye  NCO,  is  connected  to  the  CSG  on  the 
SIGINT  GLOBIXS,  exchanging  voice, 
COPCOM  reports,  message,  and  data  files, 
which  appear  on  the  SIGINT  position  end  ter¬ 
minals  (e.g.,  FASTT,  secure  telephone,  mes¬ 
sage  terminal).  In  Washington,  the  Naval  Op¬ 
erational  Intelligence  Center  (NOIC)  is  con¬ 
nected  to  the  CCC  ASW  centers  exchanging 
similar  services  over  the  ASW  GLOBIXS.  In 
Dahlgren,  VA,  Commander  Naval  Space  Com¬ 
mand  (COMNAVSPACECOM)  shares  similar 
services  logically  with  the  SEW  cell  in  the 
Norfolk  CCC.  See  figure  4-12. 
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Physically,  however,  these  services  can 
be  provided  through  any  of  the  services  shown  in 
figure  4-1,  provided  the  service  is  available  at 
the  node  and  CCC  location.  Figure  4-12  is 
redrawn  to  depict  physical  connections  in  figure 
4-13. 

Providing  GLOBIXS  services  to  a  com¬ 
mand  center,  then,  simply  means  physical  con¬ 
nection  to  the  bearer  service  through  the  bearer 
service  switch  and  the  GLOBIXS  communica¬ 


tions  processor  to  a  FASTT  terminal  that  hosts 
the  GLOBIXS  operational  Human-Machine  In¬ 
terface  (HMI).  Extending  that  concept,  then,  a 
large  command  center  serviced  by  several  bearer 
services  may  subscribe  to  a  number  of  GLOBIXS, 
the  operators  of  which  perhaps  sit  side  by  side  on 
each  watch.  See  figure  4-14. 

In  the  next  chapter,  we  will  examine  the 
functions  of  the  second  pillar  of  the  architecture, 
the  CCC. 
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RELATED  PROGRAMS 

Automatic  Digital  Network  (AUTODIN):  AUTODIN  is  a  digital  record  traffic  system  operated  as  part  of  the  DCS. 
AUTODIN  traffic  is  transmitted  via  the  Defense  Switched  Network  (DSN)  and  provides  world-wide  connectivity  to  the  U.S . 
unified  and  specified  commands  and  to  the  Services.  The  AUTODIN  system  will  be  phased  into  the  Defense  Message  System 
(DMS)  by  the  year  2000. 

Automated  Network  Control  Center  (ANCC):  The  ANCC  is  a  shore-based,  interactive,  real-time  system  rapaM*  of 
facilitating  the  overall  operation  of  technical  control  and  data  operation  facilities  by  automating  functions  that  are  presently 
performed  manually.  It  will  support  die  Naval  Computer  and  Telecommunications  System  (NCTS)  and  DCS  tretmirai 
control  functions  as  well  as  provide  interface  capability  for  commercial  and  DOD  transmission  systems.  The  ANCC  will  serve 
as  the  hub  for  communications  circuits  passing  through  a  shore-based  communications  station 

Base  Information  Transfer  System  (BITS):  BITS  defines  the  future  structure  of  communications  systems  cm  Navy  bases 
and  stations.  It  is  the  integrated  voice,  data,  image,  .messageT.ancUadecM»mmmiications- architecture  for  intrabase 
communications  and  support  of  ships  at  pierside.  The  target  architecture  will  be  accomplished  in  1996  and  beyond. 

Classic  Lightning  (Formerly  Navy  Key  Distribution  System  (NKDS)):  Classic  Lightning  is  a  system  designed  to 
transition  cryptographic  key  distribution  from  a  paper-based  system  to  an  automated  electronic  system. 

Communication  Support  System  (CSS):  CSS  is  a  communications  program  designed  to  enhance  battle  force  communi¬ 
cations  connectivity ,  flexibility,  and  survivability  through  multimedia  access  and  dynamic  link  sharing.  It  will  permit  users 
to  share  total  network  capacity  on  a  priority  demand  basis  in  accordance  with  a  specified  communications  plan. 

Defense  Commercial  T ele  communication  Network  (DCTN):  DCIN,  a  leased  communications  system,  is  a  DC  A  operated 
telecommunications  network  that  provides  routine  common-user  switched  voice,  dedicated  voice/data,  and  video  telecon¬ 
ferencing  services  throughout  the  United  States.  It  is  a  fully  integrated  digital  system  that  uses  a  mix  of  satellite  (TELSTAR 
3)  and  terrestrial  transmission  paths.  The  DCTN  contract  terminates  in  1996. 

Defense  Data  Network  (DDN):  The  DDN  is  a  worldwide  digital  packet  switched  network,  operated  as  a  long-haul  backbone 
transmission  system  by  the  DCA.  It  currently  provides  near-worldwide  coverage  in  support  of  operational  systems,  including 
the  World  Wide  Military  Command  and  Control  System  (WWMCCS)  and  intelligence  systems,  as  weU  as  general  purpose 
ADP  and  command-based  data  networks  with  long  haul  communications  requirements.  DDN  uses  packet-switching 
technology  and  currently  consists  of  four  separate  networks  operating  at  different  security  levels:  MTT  NFT  (unclassified), 
DSNET 1  (secret),  DSNET  2  (top  secret),  DSNET  3  (SCI).  The  three  DSNETS  are  presently  being  merged  into  a  DISNET 
that  includes  survivable  links  (through  redundancy),  and  uses  theX.25  protocol  for  network  access,  the  X.400  for  messaging, 
and  the  X.500  for  directory  services.  Bulk  encryption  is  accomplished  with  a  BLACKER  encryption  system. 

Defense  Message  System  flDMS):  DMS  is  a  flexible  X.400  based  system  that  will  provide  a  store  and  forward  service  via 
the  use  of  a  "Universal  Mailbox"  supporting  the  full  range  of  information  media.  Today’s  DMS  consists  of  the  AUTODIN 
and  DDN  E-Mail.  Over  the  next  3-4  years,  E-Mail  will  migrate  from  the  DOD  Simple  Mail  Transfer  Protocol  (SMTP)  to 
the  Government  Open  System  Interconnection  Protocol  (GOSIP)  X.400.  By  1995,aDMS  implementation  will  begin  phasing 
out  AUTODIN  by  providing  an  X.400/X .500  based  system  on  DDN  that  provides  both  the  AUTODIN  (organizational)  and 
E-Mail  (individual)  grades  of  service.  DMS  will  provide  a  secure  desktop-to-desktop  messaging  system  that  will  phase  out 
AUTODIN  and  close  most  telecommunications  centers  by  die  year  2000. 

Defense  Switched  Network  (DSN):  The  DSN  is  the  primary  DOD  telecommunications  network  and  evolved  from  the 
existing  AUTOVAN  system.  It  will  provide  multi-level  precedence  and  pre-emption  for  clear  and  secure  voice)  services  in 
conjunction  with  the  Red  Switch  and  Secure  Telephone  Unit  m  (STU-III)  projects  of  the  Secure  Voice  System  (SVS).  Upon 
full  implementation  in  the  mid-1990s,  the  DSN  will  interconnect  all  U.S.  military  bases  worldwide  to  provide  terminal-to- 
terminal,  long  distance  common  user  and  dedicated  telephone,  data,  teleconferencing,  and  video  services. 
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Federal  Telecommunications  System  (FTS)  2000:  FTS2000  is  a  General  Services  Administration  (GS  A)  managed  digital 
telecommunications  system  utilizing  leased  capabilities  for  a  government- wide  network  that  will  be  interoperable  with  DSN 
and  DCTN.  It  will  provide  switched  voice,  switched  data,  video  transmission,  packet-switched  data,  dedicated  transmission 
service  (voice  to  1.544  Mbps),  and  switched  integrated  services  using  Integrated  Services  Digital  Network  (ISDN)  or  T-l 
trunks.  AT&TandU.S.SprintaretheFTS2000contractors.  Access  to  FTS2000  will  be  via  dedicated  lines  from  government 
locations  called  Service  Delivery  Points  (SDPs). 

Information  Security  (INFOSEC)  Research,  Development,  Testing  &  Evaluation  (RDT&E):  A  series  of  projects  with 
INFOSEC  and  Computer  Security  (COMPUSEC)  objectives,  conducted  in  coordination  with  the  National  Security  Agency 
(NSA)  to  provide  open  systems,  end-to-end  security  processes  (rather  than  hardware)  that  can  be  applied  to  numerous  DOD 
programs.  NSA/CSS  is  the  certification  authority  for  projects  that  are  intended  for  near-term  application  in  prototypes  or 
operational  systems  and  participates  in  projects  that  explore  technology  applications  for  attacking  and/or  protecting 
information  systems.  GLOBIXS  networks  will  provide  ample  opportunity  to  use  these  technological  solutions. 

Integrated  Tactical-Strategic  Data  NfetWofRXITDNJf  l  i  DN  is  an  architecture  consisting  of  a  multimedia,  multisystem, 
multilevel  security,  integrated  strategic  and  tactical  packet-switched  data  communications  network  based  on  non-develop- 
mental  technology  that  would  support  information  transfer  within  the  backbone  data  networks  and  over  tactical  networks. 

Navy  EHF  SATCOM  Program  (NESP):  NESP  is  the  Navy  portion  of  the  Milstar  satellite  joint  service  program  that 
focuses  on  a  limited  capacity,  antijam,  survivable,  low  probability  intercept/low  probability  detection  (LPI/LPD)  commu¬ 
nications  system  for  strategic  and  tactical  forces.  The  NESP  AN/USC-38  terminal  will  be  installed  ashore  and  afloat  on  both 
airfare,  and  subsurface  platforms.  NESP  will  be  compatible  with  the  EHF  portion  of  Fleet  Satellites  (FLTSATs)  7  and8,UHF 
Follow-On  (UFO)  satellites  4-9,  and  all  Milstar  satellites. 

Radiant  Mercury:  A  program  being  developed  by  the  Navy  to  provide  two-way  transliteration  under  which  any  bit-oriented 
or  character-oriented  format  can  be  accepted,  and  any  bit-oriented  or  character-oriented  format  can  be  generated.  It  also 
provides  sanitization  (under  NSA  certification  oversight)  that  will  permit  information  up  to  the  level  of  Special  Intelligence 
(SI)  Top  Secret  to  be  "sanitized"  to  the  level  of  General  Service  (GENSER)  Secret. 
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CHAPTER  5 

CINC  COMMAND  COMPLEX  (CCC) 


SUMMARY 

The  second  pillar  of  the  Copernicus  Architecture  is  the  CINC  Command  Complex  (CCC).  Although  the 
organizational  and  doctrinal  structure  of  the  CCCs  will  be  determined  by  the  Fleet  CINCs  (FLTCINCs),  the  technological 
manifestation  of  the  CCCs  wifibeidelfical.  Itis  currwtdj/ planned  to  construct  three  complexes,  one  eaih  in  Oahu,  HI; 
Norfolk,  VA;  and  Naples,  Italy, 

The  CCC,  as  envisioned  in  this  architecture,  would  include  a  number  of  existing  organizations  brought  together 
technologically  by  common  workstations  connected  toa  metropolitan  area  network  (MAN)  using  common  bearer  services 
available  in  that  area,  like  foe  Global  Information  Exchange  System  (GLOBIXS),  the  CCC  is  a  virtual  network.  The  CCC 
MAN  would  provide  the  “information  highway”  over  which  GLOBIXS  and  Tactical  Data  Information  Exchange  System 
(TADIXS)  data  would  travel,  as  well  as  that  data  generated  at  the  CCC. 

the  CCCMAN  woitdtibe  connected  to  many  local  area  networks  (LANs)  contained  within  foe  organizations  that 
collectively  make  up  the  CCC.  Recalling  fromChapter  4  that  the  GLOBIXS  terminate  into  the  CCCs,  andrecognizing  that 
theCCCisaMANqntowhichanyorganizationcould(ifpermitted)join,foeCCCshouldbeviewedasanextremelyflexible 
construct  that  could  include  the  Navy;  joint,  non-Department  of  Defense  (DOD)  agencies;  and  allied  organizations  as 
desired  by  the  CINC. 

Significant  differences  exist,  however;  between  a  GLOBIXS,  which  is  an:  aggregation  of  “communities  of 
common  interest,"  and  foe  CCC,  which  is  an  aggregation  of  CINC  command  structures  ashore. 

As  a  result  of  that,  and  because  theater  focus  in  a  post-Cold  War  world  will  likely  be  more  divergent  than  the  past, 
the  CCCs  undoubtedly  will  becbnffguied  somewhat  differently  in  each  theater.  Moreover,  itisconceiyablefoatone  theater 
may  desire  foe  unified  CCC  model,  and  another  only  the  Navy  implementation.  Such  differences,  as  long  as  the 
architectural  standards  are  common,  are  inevitable  and,  indeed,  desirable  because  they  allow  the  commander —  the  center 
of  this  architecture’s  universe —  foe  latitude  to  restructure  his  command  and  control  when  necessary  over  foe  course  of 
several  decades. 

Through  the  CCC  and  Tactical  Command  Center  (see  chap.  7)  interaction,  foe  command  and  control  processes 
of  planning,  assessing,  observing,  executing,  and  reporting  are  structured  with  respect  to  command  level.  Differences  are 
evident  in  attributes:  timeliness  of  processing,  level  of  hierarchical  view  of  foe  problem  (global,  theater,  scene  of  action), 
and  volumes  of  information  stored,  retrieved,  and  processed.  A  broad  range  of  computational  capabilities  also  are  common 
across  command  levels:  arithmetic,  geometric,  statistics/probabilities,  and  conversions.  These  and  other  types  of 
commonalities  suggest  that  at  equal  command  levels,  there  will  be  a  high  degree  of  commonality  in  required  systems 
functions.  At  ofoer  levels  in  foe  hierarchy,  foercisstilladegrceofcommonality.butlcss  than  thaifoundamong  equal  levels. 

These  considerations  become  evident  in  foe  amount  of  redundancy  in  the  requirements  of  the  CCC  and  TCC.  This 
suggests  that  a  modular  design  for  foe  CCC  and  TCC  configurations  is  a  rational  approach.  Common  data  base  structures, 
dictionaries,  and  management  techniques  are  possible,  as  are  common  application  programs,  display  generators  and 
displays,  and  communications  interface  and  processing  algorithms.  Theseattributcsof  commonality  and  modularity,  while 
allowing  for  unique  applications  tailored  to  warfare  mission  area  and  command  level,  are  characteristics  of  foe  Copernicus 
concept 
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DISCUSSION 

The  second  pillar  of  the  Copernicus 
Architecture  is  the  CCC.  Although  the  organi¬ 
zational  and  doctrinal  structure  of  the  CCCs  will 
be  up  to  the  FLTCINCs,  the  technological  mani¬ 
festation  of  the  CCCs  will  be  identical1.  It  is 
currently  planned  to  construct  three  complexes, 
one  each  in  Oahu,  HI;  Norfolk,  VA;  and  Naples, 
Italy. 

The  CCC  as  envisioned,  would  include  a 
number  of  existing  organizations  brought  to¬ 
gether  technologically  by  common  workstations 
connected  to  a  MAN  using  common  bearer 
services  available  in  that  area.  Like  the 
GLOBIXS,  the  CCC  will  be  a  virtual  network. 
The  CCC  MAN  would  provide  the  “information 
highway”  over  which  GLOBIXS  and  TADIXS 
data  would  travel,  as  well  as  that  data  generated 
at  the  CCC. 

The  CCC  MAN  would  be  connected  to 
many  LANs  contained  within  the  organizations 
that  collectively  make  up  the  CCC.  Figure  5-1 
shows  a  conceptual  CCC  connected  to  other 
MANs  through  the  GLOBIXS.  Recalling  from 
Chapter  4  that  the  GLOBIXS  terminate  into  the 
CCCs  and  recognizing  that  the  CCC  is  a  MAN 

1  In  this  chapter,  we  will  discuss  the  CINC  Command  Complex 
as  a  principally  Navy  infrastructure.  However,  we  do  so  in  die 
current  absence  of  direction  from  DOD  and  the  unified  com¬ 
manders  to  implement  the  architecture  in  a  joint  construct 
Copernicus  was  intended  from  its  conception  to  be  a  Joint 
architecture.  At  this  writing  the  current  FLTCINC  structure  is 
partially  joint:  that  is,  the  intelligence  centers  have  merged  in  the 
Joint  Intelligence  Center  in  the  Pacific  theater  and  the  Adantic 
Intelligence  Center  in  that  theater.  We  believe  implementation 
of  the  CCC  pillar  will  be  evolutionary  and  will  reflect  the 
continuing  trend  toward  unified  command  centers.  The  reader 
is  asked  to  bear  in  mind  that  the  Navy  only  model  discussed 
above  is  intended  to  be  a  subset  of  the  eventual  Unified  CINC 
Command  Complex. 


onto  which  any  organization  could  (if  permitted) 
join,  the  CCC  should  be  viewed  as  an  extremely 
flexible  construct  that  could  include  Navy;  joint, 
non-DOD  agencies;  and  allied  organizations  as 
desired  by  the  CINC.  Figure  5-2  shows  a 
strawman  PACFLT  CCC  connected  to  the  other 
Services  and  USCINCPAC. 

Significant  differences  exist,  however, 
between- a  GLOBIXS,  which  is  an  aggregation ' 
of  “communities  of  common  interest,”  and  the 
CCC,  which  is  an  aggregation  of  CINC  com¬ 
mand  structures  ashore. 

As  a  result  of  that,  and  because  theater 
focus  in  a  post-Cold  War  world  will  be  more 
divergent  than  the  past,  the  CCCs  undoubtedly 
will  be  configured  somewhat  differently  in  each 
theater.  Moreover,  it  is  conceivable  that  one 
theater  may  desire  the  unified  CCC  model,  and 
another  only  the  Navy  implementation.  Such 
differences,  as  long  as  the  architectural  stan¬ 
dards  are  common,  are  inevitable  and,  indeed, 
desirable  because  they  allow  the  successive  com¬ 
manders  the  latitude  to  restructure  his  command 
and  control  as  he  wishes  over  the  course  of 
several  decades. 

Moreover,  the  transition  from  compo¬ 
nent  CINC  to  unified  CINC,  coupled  with  the 
potential  changes  in  the  number  of  unified  com¬ 
manders,  portends  a  lengthy  adjustment  period 
for  command  centers  ashore.  As  architects,  we 
recognize  the  need  to  develop  a  CCC  that  can 
accommodate  either  design,  and  can  do  so,  if 
necessary,  differently  on  either  coast.  Doing  so 
may  mean  developing  the  Navy  CCC  from  the 
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Figure  5-2.  PACFLT  Command  Complex 
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start  as  a  building  block  of  a  future  unified  CCC. 
In  the  event  that  the  architecture  is  adopted  for 
joint  use,  creating  the  unified  CCC  is  simply  a 
question  of  doctrine  and  connectivity.  In  prac¬ 
tice,  the  architecture,  with  its  already-joint 
GLOBIXS  structure  and  its  DOD-approved 
building  blocks  (e.g.,  DTC-II),  may  be  seen  as  a 
de  facto  solution  to  unified  commanders,  and  the 
development  of  the  unified  CCC  will  be  an 
iterative  process  from  the  Navy  structure. . . 

Therefore,  at  this  writing,  the  precise 
configuration  of  the  Copernicus  CCC  in  each 
theater  is  still  under  review  by  the  FLTCINCs 
and  OP-094,  who  responds  to  their  require¬ 
ments.  It  is  important  to  realize,  however,  that 
while  precise  configuration  remains  in  question, 
the  fundamental  building  blocks  of  the  CCC  are 
not.  It  is,  therefore,  possible  to  describe  CCC 
operations  in  some  detail. 

ORGANIZATIONAL  BUILDING 
BLOCKS 

There  are  six  organizational  building 
blocks  envisioned  to  comprise  the  core  of  a 
Navy  CCC. 

First  is  the  Fleet  Command  Center 
(FCQ,  which  is  discussed  at  length  later  in  this 
chapter. 

Second  is  a  virtual  “center”,  the  opera¬ 
tions  watch  center,  which,  perhaps,  would  be  a 
subset  of  the  CCC  MAN  rather  than  a  physically 
co-located  structure.  The  Operations  Watch 


Center,  like  the  GLOBIXS,  would  be  selected 
by  "toggling  on"  specific  desks  and  would 
interactively  connect  with  watchstanders  from 
intelligence  centers,  the  theater  Anti-Submarine 
Warfare  (ASW)  Center,  the  Space  and  Elec¬ 
tronic  Warfare  (SEW)  Center,  and  the  Research 
Center2,  as  well  as  other  watchstanders  the  CINC 
might  desire  to  suit  a  particular  mission  (e.g., 
weather,  logistics.)  The  Operations  Center  is 
best  .viewed  as  the  gateway  for  the  Composite 
Warfare  Commander  (CWC)  into  the  shore 
GLOBIXS  structure — a  collection  of  GLOBIXS 
“anchor”  desks  and  other  personnel  aggregated 
to  suit  the  mission  being  executed. 

The  structure  of  the  Operations  Watch 
Center  is  variable  and  is  achieved  in  a  similar 
manner  to  the  GLOBIXS  “toggling”  process 
presented  in  the  previous  chapter.  Selected 
desks  on  the  MAN  would  comprise  it;  some  for 
one  mission,  others  for  a  second  mission.  The 
Operations  Watch  Center  would  provide  tai¬ 
lored  support  to  the  tactical  commander  afloat3 
and  manage  the  flow  of  information  in  accor¬ 
dance  with  the  CWC’s  command  and  control 
plan,  selected  from  a  future  Naval  Warfare  Pub¬ 
lication  (NWP)  matrix  that  would  describe  Co¬ 
pernicus  GLOBIXS-TADIXS  configurations. 

The  Operations  Watch  Center  is  the  heart 
of  the  architecture  ashore  and  will  be  connected, 
as  will  be  the  GLOBIXS,  via  the  CCC  MAN  to 
the  other  organizations  that  make  up  the  CINC 
Complex. 


2  See  discussion  pg  5-5. 

3  . 

Or  JTF,  or  component  command  in  the  unified  CCC  construct 
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A  third  core  organization,  the  SEW  Cen¬ 
ter  would  have  the  responsibility  for  strategic 
and  theater-level  SEW,  including  operational 
deception  (OPDEC)  and  operational  security 
(OPSEC.)  As  the  doctrine  of  SEW  develops, 
this  may  be  constructed  as  a  single  center  con¬ 
nected  to  all  three  CCCs  or  a  series  of  three 
smaller  organizations  located  near  the  CINCs 
themselves4. 

Fourth,  the  Research  Center,  a  modem 
day  electronic  library,  eventually  will  be  needed 
to  provide  a  data-retrieval  capability  for  the 
CCC  through  the  data  base  GLOBIXS.  The 
Research  Center  also  would  house  the  file  serv¬ 
ers  and  common  data  bases  for  the  CCC  MAN. 

Fifth  is  the  Joint  Intelligence  Center 
(JIC)5,  which  has  the  following  Navy  compo¬ 
nents: 

•  The  Fleet  Intelligence  Center  (FIQ  would  pro¬ 
vide  an  interface  with  the  imagery  GLOBIXS 
and  the  imagery  TADIXS; 

•  The  Fleet  Ocean  Surveillance  Intelligence  Cen¬ 
ter  (FOSIC)  would  provide  operational  intelli¬ 
gence  (OPINTEL)  for  both  maritime  and  over¬ 
land  operations;  and 

•  The  Cryptologic  Support  Group  (CSG)  would 
provide  the  interface  between  SIGINT  GLOB  IXS 
subscribers  ashore  and  the  corresponding 
TADIXS  afloat. 


4  The  SEW  center  described  above  is  currently  under  active 
discussion  among  the  FLTCINCs,  OPNAV,  and  the  usual 
fleet  comanders.  In  addition  to  the  functions  listed,  the  SEW 
center  is  also  envisioned  to  incorporate  the  CSS  GLOBIXS/ 
TADIXS  interface.  See  chap  6. 

5  For  simplicity,  we  will  refer  to  die  JIC  in  the  remainder 
of  this  document,  intending  by  that  term  to  mean  both 


Finally,  the  ASW  centers  in  the  CCC 
would  similarly  interface  with  the  ASW 
GLOBIXS  and  the  ASW  TADIXS. 

CCC  AND  TCC  COMMONALITIES 

The  Copemican  CCC  will  serve  as  the 
centralized  command  and  control,  communica¬ 
tions  and  computers  and  intelligence  (C4I)  cen¬ 
ter  for  implementation  of  the  missions  assigned 
to  the  CINC.  It  supports  the  commander  by 
processing,  displaying,  and  disseminating  or¬ 
ganic  and  non-organic  information  (including 
national  and  theater  sensor  information)  to  pro¬ 
vide  a  clear  picture  of  operations  within  the 
theater.  This  information  is  the  basis  for  plans  of 
action  and  force  direction  decisions. 

Through  the  interaction  of  the  CCC  and 
the  TCC,  the  command  and  control  processes  of 
planning,  assessing,  observing,  executing,  and 
reporting  are  structured  with  respect  to  com¬ 
mand  level.  Differences  are  evident  in  attributes: 
timeliness  of  processing,  level  of  hierarchical 
view  of  the  problem  (e.g.,  global,  theater,  scene 
of  action),  and  volumes  of  information  stored, 
retrieved,  and  processed.  A  broad  range  of 
computational  capabilities  are  also  common 
across  command  levels:  arithmetic,  geometric, 
statistics/probabilities,  and  conversions,  for  ex¬ 
ample.  These  and  other  types  of  commonalities 
suggest  that,  at  equal  command  levels,  there  will 
be  a  high  degree  of  commonality  in  required 
system  functions.  At  other  levels  in  the  hierar¬ 
chy,  there  is  still  a  degree  of  commonality,  but 
less  than  that  found  among  equal  levels. 
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These  considerations  become  evident  in 
the  amount  of  redundancy  in  the  requirements  of 
the  CCC  and  TCC  and  suggests  a  modular  de¬ 
sign  for  the  CCC  and  TCC  configurations  is  a 
rational  approach.  Common  data  base  struc¬ 
tures,  dictionaries,  and  management  techniques 
are  possible,  as  are  common  application  pro¬ 
grams,  display  generators  and  displays,  and  com¬ 
munications  interface  and  processing  algorithms. 
These  attributes  of  commonality  and  modular¬ 
ity,  while  allowing  for  unique  applications  tai¬ 
lored  to  warfare  mission  area  and  command 
level,  are  characteristics  of  the  Copernicus  con¬ 
cept 

In  addition  to  the  six  core  organizations 
above,  the  CCC,  as  a  Copemican  pillar,  will  also 
include  a  number  of  general  and  special  purpose 
command  cells  that  are  integral  to  the  CINC’s 
exercise  of  command  and  control.  These  centers 
may  be  located  within  a  relatively  small  radius 
of  the  CINCs  principal  command  center  or  at 
some  distance  from  the  CINC  area.  They  may 
also  be  conceivably  shared  by  all  CINCs,  con¬ 
nected  to  all  three  MANs. 

Each  center  will  be  served  by  a  com¬ 
puter-based  system  meeting  its  particular  mis¬ 
sion  needs  and  the  Copernicus  architectural  stan¬ 
dards  (see  chap.  8).  The  Copernicus  goal  is  to 
connect  these  “centers”  doctrinally  and  techno¬ 
logically  into  a  cohesive  organization. 

Within  all  CCC  centers,  a  local  area 
network  connects  computer-based  systems  and 
system  components.  The  local  area  network 
provides  gateways  to  a  larger  (metropolitan  area) 


network  that  connects  the  centers  and  also  pro¬ 
vides  gateways  to  afloat  (TADIXS)  through  the 
Communications  Support  System  (CSS)  and  to 
shore  GLOBIXS  networks. 

Through  the  CCC,  the  Copernicus  ob¬ 
jective  is  to  provide  to  the  CINCs  and  subordi¬ 
nate  commanders  a  flexible  set  of  system  capa¬ 
bilities  that  support  tactical  and  strategic  com¬ 
mand  functions  and  responsibilities  as  well  as  a 
second,  and  interrelated,  set  of  system  capabili¬ 
ties  that  aid  in  developing  products  that  support 
the  command  functions  (e.g.,  intelligence, 
weather,  surveillance). 

OPERATIONAL  CCC  MODEL 

As  a  means  to  the  CCC  end  goal,  the 
exploitation  of  common  functional  areas  can  be 
achieved  by  unbinding  the  development  pro¬ 
grams  and  converging  the  various  command  and 
support  functions  under  a  common  program 
umbrella.  The  discussion  that  follows  focuses 
on  a  subset  of  CCC  command  and  command 
support  centers  and  builds  a  partial,  operational 
model  of  a  future  Navy  CCC.  The  model  uses  an 
over-the-horizon-targeting  (OTH-T)  mission  as 
operational  context  and  assigns  missions  no- 
tionally6. 


6  In  the  model  that  follows,  mission  responsibilities  and  CCC 
Centers  should  be  seen  as  notadonaL  References  are  here  only 
to  illustrate  a  hypothetical  future  CCC  capability. 
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The  Fleet  Command  Center  (FCC) 

In  the  operational  CCC  OTH-T  model, 
the  FCCs  support  the  FLTCINCs  in  the  exercise 
of  theirresponsibilities  as  naval  component  com¬ 
manders.  FCC  functional  interfaces  are  shown 
in  figure  5-3.  The  FCCs  would  support  the 
FLTCINCs  to: 

•  Implement  theater  USCINCs'  directives  and  poli —  - 
cies; 

•  Allocate  combat  ready,  logistically  sustainable, 
tactical  naval,  naval  air,  and  United  States  Ma¬ 
rine  Carps  (USMC)  forces  to  joint  commanders 
as  directed  by  unified  commanders; 

•  Prepare,  evaluate,  promulgate  and  supervise 
plans,  orders,  and  tactical  decisions; 


•  Allocate/reallocate  assigned  resources; 

•  Schedule  employment  of  forces; 

•  Assess  and  predict  tactical  situations  and  fleet 
readiness; 

•  Support  miscellaneous  command  support  activi¬ 
ties  such  as:  transit  planning;  search  and  rescue 
operations;  and  civilian  catastrophe  relief;  and 

•  Support  the  reconstruction  and  evaluation  of 
completed  actions/exercises. 

In  the  OTH-T  mission  example,  the  CINC 
through  the  FCC  would: 

•  Assign  the  mission  to  subordinate  forces; 

•  Allocate  resources  (e.g.,  ships,  aircraft,  subma¬ 
rines,  weapons,  fuel,  communications); 
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Figure  5-3.  FCC  Functional  Interfaces 
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*  Monitor  execution  of  the  mission; 

*  Keep  higher  echelon  authorities  advised  of  mis¬ 
sion  status  (along  with  status  of  all  FLTCINC 
missions  and  forces);  and 

*  Modify  mission  objectives  and  constraints  as 
necessary  to  meet  changing  national  and  theater 
directives. 

To  perform  these  functions,  FCC  per¬ 
sonnel  must  provide  mission  direction  to  subor¬ 
dinate  forces.  Mission  direction  may  be  pro¬ 
vided  as  a  file  transfer  or  a  directive  message 
stating  policy.  Information  transfers  will  be  Case 
2  or  3  data,  depending  on  mission  urgency  (see 
chap.  3). 

FCCs  must  manage  resources  at  the  the¬ 
ater  level  through  use  of  Case  2  and  3  file 
transfer.  In  many  cases,  information  transfers 
will  be  among  FCC  subordinates  within  the 
LAN  or  MAN.  In  other  cases  (for  example, 
exchanging  information  with  fuel  management 
activities),  software  bridges  will  be  required  to 
support  query/response  and  file  transfers. 

One  resource  to  be  managed  will  be 
communications.  As  noted  in  connection  with 
related  programs,  the  CSS  software  veneer  and 
human-machine  interface  (HMI)  will  be  used  to 
manage  communications.  In  addition  to  manag¬ 
ing  U.S.  Navy  resources,  FCC  would  coordinate 
with  other  component  commanders  and  with 
supporting  CINCs  (e.g.,  to  assure  flow  of  re¬ 
quired  munitions  and  repair  parts  by  CINCU.S. 
Transportation  Command). 


To  monitor  mission  execution,  the  FCC 
could  receive  Case  1,  2,  and  3  track  data  (in 
Copernicus  Common  format)  from  subordinate 
forces  and  prepare  summary  reports  (as  Case  2 
and  3  file  transfers)  for  higher  echelons.  Case  2 
OPNOTES  will  support  analyst-to- analyst  ex¬ 
changes  at  all  levels  over  both  GLOBIXS  and 
TADIXS.  The  FCC  is  expected  to  be  the  “an¬ 
chor”  for  the  Command  GLOBIXS. 

Mission  modifications  may  be  in  the 
form  of  Case  2  or  3  file  transfers  (e.g.,  modifying 
a  “no-attack”  zone  in  which  target  surface  ships 
may  not  be  engaged,  for  example)  or  as  mes¬ 
sages  over  Navy  Information  Exchange  System 
(NA  VIXS),  if  necessary,  stating  new  constraints 
(e.g.,  revised  rules  of  engagement). 

The  Submarine  Operations  Control  Center  (SOCC) 

Submarine  Operations  Control  Centers 
(SOCCs)  in  Pearl  Harbor,  Norfolk,  and  Naples 
are  pan  of  the  Pacific,  Atlantic,  and  Naples 
CCCs,  respectively.  SOCC  interfaces  are  shown 
in  figure  5-4.  These  centers  support  submarine 
force  and  submarine  group  commanders  to: 

•  Plan,  train,  and  act  as  the  USCINCs'  executive 
agent  for  command  and  control  of  strategic  sub¬ 
marines; 

•  Plan,  train,  and  exercise  command  and  control  of 
independent  operating  tactical  submarines  and 
submarine  rescue  surface  and  deep  submergence 
platforms; 

•  Plan,  train,  coordinate  and  ensure  the  safety  of 
tactical  submarines  operating  with  other  naval 
forces; 
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•  Conduct  post-exercise/mission  reconstruction 
and  analysis; 

•  Exercise  water  space  management  in  coordina¬ 
tion  with  FLTCINC’s  area/sector  ASW  com¬ 
manders  and  bilateral  force  commanders; 

•  Maintain  direct  liaison  with  area/sector  ASW 
commanders  for  antisubmarine  warfare  opera¬ 
tions; 

•  Prepare,  operate,  and  manage  submarine  broad¬ 
casts  and  ship-shore  links;  and 

•  Direct  submarine  search  and  rescue  operations 
and  coordinate  employment  of  submarines  in 
other  search  and  rescue  operations. 

The  SOCCs  would  report  to  the  FCC  or 
the  unified  CINC  command  center  as  appropri¬ 
ate  and  communicate  as  a  peer  with  other  subor¬ 


dinate  nodes.  In  the  OTH-T  mission  context, 
SOCC  operates  U.S.  submarine  forces  in  offen¬ 
sive  and  defensive  roles.  The  SOCC  is  one  of  the 
subordinates  that  could  receive  OTH-T  mission 
tasking  and  must  coordinate  with  peer  command 
nodes  to  execute  the  tasking. 

SOCC  would  provide  a  strong  informa¬ 
tion  management  capability  for  submarine  forces. 
Due  to  the  unique  nature  of  submarine  commu¬ 
nications,  information  must  be  reviewed  and 
filtered  at  SOCC  before  being  transmitted  to  the 
submarine  force.  In  the  single  case  of  submarine 
support,  therefore,  even  Case  1  data  may  expe¬ 
rience  some  delay.  The  principal  format  of 
information  transfer  will  be  Copernicus  Com¬ 
mon  sensor  reports  and  other  file  transfers. 
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Exchange  ofinfonnation  with  the  SOCC  trol  over  assigned  ASW  forces.  Shore  ASW 

provides  a  good  example  of  security  require-  Command  Centers  are  located  in  Makalapa, 

ments.  The  SOCC  must  provide  timely  and  Norfolk,  Kami  Seya,  and  Naples.  SACC  func- 

accurate  information  concerning  submarine  force  tional  interfaces  are  shown  in  figure  5-5.  These 

units,  but  information  must  be  disclosed  only  to  facilities  would  exercise  control  primarily  over 

persons  with  proper  clearance  and  need-to-know.  maritime  patrol  aircraft  (MPA)  and  Integrated 

CCC  information  handling  doctrine  must  pro-  Undersea  Surveillance  System  (IUSS)  units; 

vide  effective  protection  without  delaying  infor-  however,  surface  ships  and  other  units  may  also 

mation  flow.  be  assigned  via  the  appropriate  task  group  com¬ 

mander. 


Shore  ASW  Command  Centers  (SACC)  In  the  OTH-T  mission,  the  SACC  and 

subordinate  nodes  will  be  tasked  with  specific 
Shore  ASW  Command  Centers  (S  ACCs)  operational  support  roles.  This  tasking  would 

(and  subordinate  nodes:  Regional  ASW  Com-  probably  include  reconnaissance  and  ASW  de¬ 
mand  Center  [RACC],  Main  Evaluation  Center  fense  of  surface  OTH-T  units.  The  SACC  must 

[MEC],  and  ASW  Operations  Center  coordinate  with  the  SOCC  and  with  allied  ASW 

[ASWOC]),  would  exercise  command  and  con-  forces. 
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The  S  ACC  could  set  doctrine  for  how  Main  Evaluation  Centers  (MEC) 

Case  1 , 2,  and  3  data  flows  to  and  among  subor¬ 
dinate  units.  Naval  Oceanographic  Processing  MECs  would  process  acoustic  informa- 

Facilities  (NOPF),  for  example,  may  exchange  tion  received  from  multiple  facilities  to  locate, 

OTH-T-related  information  through  a  special,  identify,  and  track  submarines.  That  informa- 

unique  GLOBIXS  managed  by  the  Surveillance  tion  can  be  correlated  with  other  submarine 

Direction  System  (SDS)  under  doctrinal  guid-  intelligence  sources  to  produce  threat  subma- 

ance  provided  by  S  ACC.  Case  1  data  will,  how-  rine  location  and  predicted  movements  and/or 

ever,  flow  directly  from  a  NOPF  to  fleet  units  identity  by  hull  or  class.  The  product  can  be 

through  CCC  without  delay.  Other  Case  data' '  disseminated  to  FCC,  SOCC,  SACC,  and 
would  probably  not  flow  directly  to  the  fleet  ASWOC  users.  At  the  FCC,  the  MEC  product 

unless  ASW  became  an  important  threat  to  the  would  be  correlated  with  other  ocean  surveil- 

accomplishmentofthisOTH-T  mission.  Figure  lance  information.  In  this  OTH-T  mission, 

5-6  shows  a  notional  GLOBIXS  to  CCC  con-  MEC  data  can  make  a  secondary  contribution  to 

nectivity.  mission  accomplishment. 
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FLEET  NUMERICAL  OCEANOGRAPHIC 
CENTER  (FNOC) 

The  FNOC  would  provide  natural  envi¬ 
ronmental  data  (current  and  forecast  status)  for 
periodic  and  tailored  reporting.  Periodic  report¬ 
ing  and  tailored  reporting  are  in  response  to 
requirements  of  commanders. 

OTH-T  mission  environmental  -support 
focuses  on  two  areas:  1)  support  for  aviation 
operations  (manned  and  unmanned)  and  2)  sup¬ 
port  for  reconnaissance.  Almost  all  of  this 
information  is  Case  2  data,  provided  by  file 
transfer  on  an  environmental  (i.e.,  support) 
TAD  DCS.  Forces  afloat  also  provide  environ¬ 
mental  information  to  assist  in  predictions.  This 
information  is  sent  by  file  transfer  on  an  environ¬ 
mental  TAD  DCS  from  ship  to  shore. 

Joint  Intelligence  Centers  (JIC) 

JICs  produce  threat  orders  of  battle,  char¬ 
acteristics  and  performance  data,  general  and 
tailored  intelligence  estimates,  threat  submarine, 
locations/characteristics,  imagery  interpretation, 
and  targeting  support.  These  products  are  dis¬ 
seminated  to  national,  fleet,  and  joint  users. 
These  centers  combine  with  the  FOSICs  and  are 
augmented  with  joint  personnel  to  become  the 
JIC  (Pacific)  and  the  Atlantic  Intelligence  Cen¬ 
ter  (AIC). 

In  the  OTH-T  mission  context,  contribu¬ 
tions  of  the  JIC  are  of  great  importance.  For 
Strike  Warfare  operations,  JIC  order  of  battle 


information  (Case  1  and  2  data,  provided  by  file 
transfer)  is  vital  to  mission  planning  and  battle 
damage  assessment  (BDA.)  For  Anti-Surface 
Warfare,  JIC  technical  data  base  information 
(also  Case  1  and  2  data,  provided  by  file  transfer) 
would  help  to  assure  the  correct  ship  is  targeted 
and  that  appropriate  C4I  Counter  Measures  (e.g., 
jamming  and  radiation  suppression  munitions) 
would  be  provided  to  the  strike  package. 


Similarly,  JIC  requires  updates  of  infor¬ 
mation  from  forces  afloat  This  information 
may  be  Case  1  through  Case  3  and  may  be 
provided  by  imagery  or  file  transfer. 

Naval  Control  of  Shipping 
Organizations  (NCSO) 

The  NCS  Os  would  generate  convoy  com¬ 
positions,  assembly  plans,  route  plans,  dispersal 
plans,  and  convoy  protection  plans.  These  plans 
are  implemented  by  the  NCSO  when  the  use  of 
convoys  of  merchant  shipping  is  directed  by  the 
Joint  Chiefs  of  Staff.  Convoy  progress  is  moni¬ 
tored  to  ascertain  needs  for  rerouting  and/or 
additional  protection  against  air,  surface,  or  sub¬ 
marine  attacks.  In  the  OTH-T  mission  context 
information  from  NCSO  is  used  by  appropriate 
elements  to  prevent  inadvertent  attack  on  friendly 
or  neutral  shipping. 

OPERATIONAL  MODEL  CCC 

The  critical  functions  discussed  in  the 
previous  pages  were  derived  from  an  examina- 
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tion  of  user  functions,  current  systems  capabili¬ 
ties,  and  system  interface  requirements.  They 
lead  to  four  subsystem  categories  in  an  opera¬ 
tional  model: 

•  Information  dissemination; 

•  Information  processing; 

•  Briefing  and  display;  and 

•  Facilities. 


successor)  environment  that  provides  a  consis¬ 
tent  interface  to  all  applications. 

An  open  system  architecture  maintains 
the  flexibility  needed  to  accommodate  changing 
requirements  and  to  ensure  continuing 
interoperability.  The  following  capabilities  are 
needed  in  the  information  processing  subsystem: 


Information  Dissemination  Subsystem 

The  information  dissemination  sub¬ 
system  would  connect  the  information  process¬ 
ing,  briefing  and  display,  and  communication 
equipment  within  a  command  center  and  among 
command  centers.  It  would  interface  with  net¬ 
works  to  connect  geographically  dispersed  cen¬ 
ters.  LANs,  MANs,  and  GLOBIXS  networks 
could  provide  these  connectivities  and  manage 
network  information  flows.  The  subsystem  will 
provide  all  requisite  communication  system 
interoperability,  compatibility,  adaptability,  se¬ 
curity,  reconfigurability,  system  management, 
and  security.  It  could  function  in  secure  voice, 
imagery,  data,  and  video  modes. 

Information  Processing  Subsystem 

The  information  processing  subsystem 
would  provide  a  single,  integrated  capability  for 
users  to  access  all  processing  resources  based  on 
their  requirements  and  authorized  data/applica¬ 
tion  program  accesses.  Each  user  could  access 
all  applications  through  a  “single  window”  (or 


•--  Extemal -data  interfaces  with  all  terminating 
networks  and  dedicated  links; 

•  Internal  data  interfaces  with  existing  and  evolv¬ 
ing  systems; 

•  Data  protocol  compatibility  with  external  sys¬ 
tems; 

•  Automated  message  handling; 

•  Multilevel  security  (i.e.,  secure  handling  of  in¬ 
formation  at  multiple  levels  of  classification 
without  compromise  of  information  confidenti¬ 
ality  or  integrity); 

•  LANs  to  permit  authorized  sharing  of  intra-  and 
into’-  command  center  data,  applications,  and 
various  terminal  devices; 

•  Standardized  user  interfaces  across  all  applica¬ 
tions  and  decision  aids; 

•  Office  automation; 

•  Data  management  and  storage  in  a  relational 
data  base  environment; 

•  Integration  of  imagery  processing  into  ocean 
surveillance  and  intelligence  products; 

•  High  resolution  geographic  and  topographic 
maps  with  capabilities  to  overlay  standardized 
user-friendly  icons;  pan,  zoom,  convert,  re-reg- 
ister,  and  to  annotate  with  narrative  or  graphic 

rfafa; 
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•  User-oriented  tactical  decision  aids  including  Operational  Decision  Aids 

planning,  assessment,  and  optimization  models; 

.  Briefing  preparation;  and  Operational  decision  aids  provide  the 

ability  to  assess  operational  plans  prior  to  and 

•  Report  generation.  after  execution  to  assist  the  fleet  commander  in 

resource  allocation  and  in  evaluation  of  alterna¬ 
tive  operational  courses  of  action.  The 
Briefing  and  Display  Subsystem  Copernicus  architecture  will  allow  CCCs  to  con¬ 

duct  interactive  operational  planning  through 

The  briering  and  display  subsystem.- .  the  use  ofthe-  Command  (on  a  CINC  planning) 

would  be  comprised  of  video  switches,  control-  GLOBIXS  and  with  like  capabilities  at  sea  via 

lers,  large  screen  displays,  monitors,  and  tele-  the  appropriate  TADIXS. 
conferencing  and  audiovisual  support  equip¬ 
ment  It  would  interface  directly  with  the  infor¬ 
mation  processing  and  communication  sub-  Facility  Subsystem 

systems  and  support:  generation  of  situation 

summaries;  direct  display  of  tactical  situations  The  facility  subsystem  would  provide 

with  annotations;  television  reception;  imagery  the  space,  power,  environmental  controls,  and 
displays  registered  on  a  geographic/topographic  human  support  environment  that  is  responsive  to 

map;  and  any  display  created  by  a  CCC  sub-  needs  of  decision  makers,  watchstanders,  ana- 
scnber-  lysts,  and  maintenance  and  administrative  per¬ 

sonnel.  Self-sustainability  for  continued  opera¬ 
tions  in  an  isolated  environment  should  be  con¬ 
sidered. 


RELATED  PROGRAMS 

Ocean  Surveillance  Information  System  (OSIS)  Baseline  Upgrade  and  OSIS  Evolutionary  Development  (OBU/OED): 
The  OBU/OBE  provides  automated  receipt,  processing,  fusion  and  dissemination  of  all-source  surveillance  and  intelligence 
data  of  interest  to  fleet  and  command  authorities.  Intelligence  and  event-by-event  data  is  supplied  to  forces  afloat  for  tactical 
support  and  over-the-horizon  targeting  (OTH-T)  in  a  timely  manner. 

Operations  Support  System  (OSS):  OSS  is  a  system  evolving  from  the  functionalities  of  the  Navy  WWMCCS  Standard 
Software,  Operations  Support  Group  Prototype,  Fleet  Command  Center  Battle  Management  Program,  and  Joint  Operational 
Tactical  System  (JOTS).  The  CINC  staff  uses  JOTS  n  and  a  JOTS  variant  the  Joint  Visually  Integrated  Display  System 
(JVIDS),  in  the  current  partially  integrated  OSS.  OSS  is  converging  the  functionalities  of  these  developments  into  a  single 
system.  OSS  supports  multi-warfare  fleet  and  allied  readiness  assessments;  tactical  and  strategic  situation  assessments; 
operations  and  logistics  plan  development  and  assessment;  and  resource  allocation  planning  and  optimization,  processing, 
preparation,  and  dissemination.  The  Information  Processing  and  Dissemination  System  (IPDS)  is  being  developed  for  the 
Naples  relocation  project,  intended  to  be  the  first  Copemican  CCC. 
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AS WOC  Modernization:  ASWOC  is  a  shore-based,  on-line,  interactive,  real-time  netted  system  to  support  the  missions 
of  the  Maritime  Patrol  Aircraft  Sector  Commander.  ASWOC  provides  mission  planning  assistance,  in-flight  support  and 
post-flight  analysis  for  ASW,  ocean  surveillance,  OTH-T,  and  Anti-Surface  Ship  Warfare  (ASUW)  missions.  ASWOC  also 
supports  Battle  Force  (BF),  BattleGroup  (BG),  Surface  Action  Group  (SAG),  and  Towed  Array  Surveillance  System  (TASS) 
and  Tactical  Towed  Array  Surveillance  System  (TACTASS)  units,  operating  in  or  transitioning  through  ASWOC  sectors, 
with  pertinent  tactical  information.  The  twenty  ASWOC  sites  are  currently  undergoing  a  modernization  program  to 
transition  the  system  to  COE  hardware  and  software  elements.  The  program  incorporates  DTC-2  computers  and  selected 
COTS/GFE  software  in  a  LAN  based  architecture. 

Base  Information  Transfer  System  (BITS):  BITS  is  abackbone  scheme  for  integrating  basewidecommunicadons  systems 
in  order  to  provide  voice,  data,  image  message  and  video  communications  to  users.  Apierfacility  will  be  provided  to  interface 
ships  to  the  backbone.  BITS  will  provide  interface  to  the  DCS .  Control  and  management  will  be  through  a  central  facility. 

FleetImagerySupportTerminal(FIST):  FIST  provides  a  capability  for  worldwide  transmission  of  imagery  between  USN 
forces  ashore  and  afloat  using  military  satellite  communications  systems.  Hard  copy  imagery  is  digitized  at  the  originating 
site,  transmitted  via  satellite,  and  permanently  recorded  at  the  receiving  site.  The  receiving  site  can  display  the  imagery  on 
a  high-resolution  cathode  ray  tube  display  or  convert  the  display  to  hard  copy.  The  terminal  can  enlarge,  annotate,  and 
enhance  imagery  for  further  analysis. 

WWMCCS  ADP  Modernization  (WAM):  WAM  is  a  joint  program  to  redesign  and  replace  the  ADP  systems  within 
WWMCCS.  Key  elements  include  modernization  of  software  (translation  from  COBOL  to  Ada),  implementation  of  Joint 
Operations  Planning  and  Execution  System  (JOPES),  and  the  installation  of  additional  elements  of  the  National  Military 
Command  System  (NMCS)  as  directed.  The  Defense  Communications  Agency  (DCA)  is  the  lead  agency. 
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CHAPTER  6 

TACTICAL  DATA  INFORMATION  EXCHANGE  SYSTEMS  (TADIXS) 


REFERENCE: 

(a)  Space  and  Electronic  Warfare  Communication  Support  System  Technology 
Base  Application  Plan,  October  1990 


SUMMARY 

idoim^dEsi^  (T^X^^-will  awqijiinp«  c^lTja^c^  1^^ 

Systems  {TADIXS),  the  third  pillar  of  tire  CopefnictiS  Architecture,  r  ||| "  V  .  : 

ff./j'Mv  tire  Global  Information  firehangis  Syston  |§LO||i^)  and  He  CCG,  tire  TADIXS  are  not  physical  But 
i  ibets.  established^li^  requ^^idiin  lSea»^^^acli!C^|iy  ^ighiaalac^^ 

arebperatidna/conrtrum.ntrtcommumcario/Jsne/worfa.Tlreinfor^ 

paievka^  artfceylllik^^  about  wtoae 

to  send  data  onto  theTCC  and  CCC  networks  andhow  to  display  them.  ..... 

i  It  is  important  to  understand  that,  because  of  their  virtuality,  TADIXS  are  essentially  doctrinal  delineations  of 

"infoiMion  to  atidfiyj  tireGlJ^  %|j|yiSSlS3III 

expainbitm  of  tlieite; 

numbers  and  typesarefl%tionofcommandstnictureanddbctrine.Thus,we  should  conceive  qftheinformatioiiflbw  from  : 

thiw%mcep^planes^  operational  model 

later  in  this  chapter:  . 

§f§§§»  ;|f  First,  tire  different  tretinologicsd  '^yelopes”  in  v^hich  |jie  data  are  packaged  and  formatted  (e.g.,  Government 
I -  J|a  Gj^System  ^(^natiication  Support  System  [CSSlcwstomtprotocolsfbr 

tactical  application); 

ilk; «  :  Second,  due  qperationaldara/ayenn^tiikisp^^^  die  data  on  a  particular  TADIXS  and 

•  route  the  data  to  a  particular  commander's  workstation;  and 

•  ^^ibctr<m^muttk>n<>f4ata  fromtheTi^lXSib|#^^ 

on  the  Coponican  tactical  computers^  theEleef  All-Source  Tactical  Terminals  (FASTTs)  and  other  “engines.” 

Because  they  are  virtual  nets  and  have  acommon  engineering  basis,  Copemican  TADIXS  can  be  likened  to 
i^jll^tione a:-  madte:-  to:;^rt^ne|ibr  any '  purpose '  over ;;  aciy::  available';! 

communications  pathway  for  the  length  of  time  necessary  to  convey  the  information.  Unlike  telephone  calls, Cq^^ 
TADIXS  may  support  all  eight  formats  bf  communications  services  and  in  three  cases  of  precedence  (see  chap.  3); 
However,  tike  telephonecalls,  the  humWofTAblXSwillnotbe  fired;  instead,  they  will  beconnected  for  die  length  of 
jilmieihecessaryitb  tautspdrt  thedata:te;lte  &bsmbOTp|tiieii::^^ 

For  these  reasons,  CopermcanTADIXS  are  classified  into  four  broad  categories—  amenu  is  a  good  analogy- 
like  the  GLOBIXS  by  “communities  of  interests”;  ||f' 

liirf  CemmawfrADKShaveasthdrpurposebotiihighcommand  and  force  command,  whether  Navy,  joint,  orallied. 
*  Both  types  of  commandTADIXS  are  envisioned  as  multiformat,  with  the  former  including  video  teleconferenc- 

•-  The  seccmd  broad  category  is  the  Sup/wrfTADIXS  In  this  group,  we  include  such  streams  as  an  Environmental 
Tpii£S,aLbgisticsTADIXS|aDataBase#defra^ 
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Exchange  System  (NAVIXS),  which  as  die  nanative  message  pathway,  is  the  only  TADIXS  envisioned  to  cany 
,  that  format  AU  other  TADIXS,  including  those  other  than  Support,  are  being  designed  in  formats  other  than 
messages. 

!|I|§ *  |§  ThethirdcategcHyisDirect7argeting,whichwiliencompassseveralTADlXSthatcanbetailoredftH'alliesand 
fHtered  for  geographic  and  targeting  differences.  Direct  targeting  will  not  be  further  discussed  in  this  document 

i  •  constructed acotn^Wlaapl force;  11® 

offers  Ibotli  .iawiilfa^^  sciS5cK^coar>riyb~ : 

hicadons  capacityrequires  anew  approach  to  procuring  and  implementing  Navy’s  communications  assets.  Today,  Navy 
comnumicatioos  effectively  are  centered  on  ultra-high  frequency  (UHF).  Existing  high  frequency  (HF)  equipment  is 
antiquated,  necessitating  high  manpower  requirements  in  return  for  tow  data  throughputs.  Super-high  frequency  (SHF) 
is  only  in  adolescent  stages  in  Navy,  and  extremely-bigh  frequency^EHE)  availability.and  throughput  will  be  limited.  * 
Commercial  satellite,  like  SHF,  has  the  promise  of  adding  high  data  rate  capacity  ttiihe  Navy  afloat  platforms. 

tci>aav:  iii  bearaf^staridceis.  First,  we  have  not  invested  1 

sc^itroai^  Sej^^bec^pm 

architecture  revolves  around  the  message  aiid  is  diiven%  not  the  receiver,  it  hasproveti  extremely  difficult  to 

make  operation^  tbarions  auraming  in^^  have  not  engineered  the  meaiis  to  switch 

traffic  from  cn^SE  asset  to  another —  a  keyrequirement  in  a  jamming  environment  Instead,  as  mentioned  previously, 

:'f  Pe  ;wefraVe;never': ' 

engineered  virtual  networks  that  allow  us  to  use  the  capacity  we  do  have  efficiently. 

In  the  Copernicus  architecture,  we  propose  to  remedy  all  four  shortfalls. 


DISCUSSION 

The  new  centers  of  the  universe  for 
Navy —  the  CCC  in  “co-orbit”  with  the  TCC — 
will  share  a  common  tactical  picture  through  a 
series  of  TADIXS,  the  third  pillar  of  the 
Copernicus  Architecture. 

Like  the  GLOBIXS  and  the  CCC,  the 
TADIXS  are  not  physical  but  logical  nets,  estab¬ 
lished  at  the  request  and  in  the  mix  desired  by  the 
tactical  commander.  As  we  saw  in  Chapter  3, 
TADIXS  are  operational  constructs,  not  com¬ 
munications  circuits.  The  information  contained 
in  a  single  TADIXS  may  be  provided  via  several 


communications  circuits  or  vice  versa.  TADIXS, 
therefore,  spring  from  an  operational  decision 
about  where  to  send  data  onto  the  TCC  and  GCC 
networks  and  how  to  display  them. 

-  Simply  put,  Copemican  TADIXS,  un¬ 
like  the  current  and  planned  TADIXS  A  and  B, 
manifest  themselves  at  their  points  of  origin  and 
destination —  they  exist  at  the  CCC  and  at  the 
TCC,  but  not  en  route  to  either. 

Between  the  CCC  and  the  TCC,  TADIXS 
data  will  be  routed  over  a  virtual  network  sys¬ 
tem,  the  first  Navy  implementation  of  which 
will  be  the  CSS  (see  boxed  text  6-1). 
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:  Boxed  Text  6-1.  Communications  Support  System  (CSS) 


CSS  uses  a  communications  architecture  that 
Utilizes  multi  media  (i.e.,UHF  SATCOM,  IJHF  LOS, 

:  HF)  and  media-sharing  to  provide  imjxoved  coriununi- : 
.pfioqsfle^ 

ciency.  It  will  be  implemented  through  development  of 
new  systems  and  equipment  and  raodifications  to  exist¬ 
ing  systems  and  equipments.  Backward  compitilbility 
with  existing  systems  and  equipment  will  be  maintained 
during  transiticm  po^ods. '  • '  CSS;:  defines  kandard  haid?  • 
ware  and  interfaces,  defines  requirements  for  reusable 
software;  defines  standard  protocols,  definesa  security 
ipollcy-^'tliasi  <»mbinw  CC^^tSEC  and  COMPUSEC,  anil ' ! 
develops  plans  for  common  logistics  support  and  con¬ 
figuration  management  by  its  implementing  programs. 
The  TADIXS  pilfcir  of  Copernicus  is  manifested  by 
eoiteitBirations^ 

its  major  componentsUs«s,Communications Resources 
(ie,, radios,  transceivers,  frequencies,  channels,  timeslots, 

■ etc,)  and  a  sopvt^^ 

that  'ass ignis®  Resources  to  Users  in  accordance  with  ■; 
direction  ftd^ 


connection  plan.  Resources  provide  their  technical  per- 

BIT  status)  to  the  tactical  commander  for:  his  use  in 
selecting  which  Resource(s)  to  use  for  a  particular  User 
or  ret  of  Ustas,  or  ij»  Cppemican  tenraijoidgy,  for  a 
particular  TAD1XS dr  ^  include 

aliftmdtions  betv/eeti  thetlsefinp^^ 

:  tions  port  on ;  one  pimftHnt  ship;  shore,  aircraft, 
isttbraanne)  to  the  User  inpu^output  communications 
ports  on  another  platfoinm,  mid  includes  the  radio  fre¬ 
quency  media  (see  fig.  6B-I.1). 

li  fcll  fjsersprovide  data  m  the  following  Co^rnican 
|  operation*!  formats:  voi^,  OPNOT^,  nanadye  mes¬ 
sage,  facsimile,  Copernicus  Common  Format 
(COrcON0,  data  base  files,  imagery,  and ;  vidro  Rie-:. 
;  rourcesprovide  over-the-airdata  rates  front  7  5  bps  to  64 ;  : 
kbps,  although  data  rates  above  4.8  kbps  generally  await 
fielding  of  additional  SHF  SAT OOp  Terminals  and 
commercial  S  ATCOM  Terminals.  : . . 


HatformA 


Platform  B 


Boxed  Figure  dB-tli  Communications  Support  System  (CSS)  Ext«rhal  Interfaces 
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One  major  impact  of  the  TADIXS  will 
be  to  nearly  eliminate  the  Navy  message  as  an 
operational  format,  moving  instead  toward  the 
eight  formats  discussed  in  Chapter  3.  Informa¬ 
tion  will  be  displayed  in  the  context  of  high- 
resolution  graphics  and  imagery.  Typically  (al¬ 
though  not  absolutely)  binary  data  transfer  is 
more  efficient  from  a  communications  stand¬ 
point;  moreover,  the  current  trend  toward  more 
and  more  computing  power  in  smalleran  Asmaller-  •  ■ 
packages  soon  will  enable  sophisticated  data 
compression  and  transmission  techniques  to  re¬ 
duce  the  amount  of  data  actually  sent 

In  addition  to  virtual  networking  (and 
like  the  GLOB  DCS),  TADIXS  thus  will  provide 
a  second  major  improvement  in  information 
management  not  only  will  the  information  ve¬ 
neer —  the  mission  software  that  present  data  as 
operational  information —  be  both  more  effi¬ 
cient  and  more  powerful  than  text  but  Copemi- 
can  TADIXS  will  result  in  greater  efficiency  in 
communications  capacity. 

The  third  advantage  of  TADIXS  is  con¬ 
veyed  in  die  CSS  multimedia  capability..  In-the  - 
past  anti-jamming  techniques  were  focused  on 
thewaveformoftheSATCOMterminal.  Milstar, 
with  its  very  survivable  EHF  waveform  is  an 
example.  However,  the  trade-off  for  anti-jam 
manifested  in  the  waveform  is  clean  the  through¬ 
put  of  Milstar  is  far  less  than  the  potential  inher¬ 
ent  in  the  physics  of  the  EHF  band. 

Copernicus  recognizes  there  are  other 
alternatives  to  jamming  than  producing  an  anti¬ 
jam  waveform.  While  it  is  clear  that  tactical 


commanders  will  continue  to  require  a  core  of 
anti-jam  communications  such  as  that  provided 
by  Milstar  EHF,  even  less  critical  communica¬ 
tions —  “general  purpose”  in  the  lexicon  of 
MILSATCOM  planners  (see  fig.  6-1) —  can  be 
provided  with  jam-resistance  if  TADIXS  agility 
is  provided. 

Earlier  in  this  document  we  addressed 
theimportaneeof  operational  perspective.  When 
operational  perspective  is  considered,  a  full  media 
capability  for  ships  and  a  capability  to  move 
TADIXS  dynamically  across  the  media  assigned 
to  the  tactical  commander  is  an  affordable,  suit¬ 
able,  and  feasible  method  of  achieving  this  jam- 
resistance.  This  operational  flexibility  is  at  the 
heart  of  the  Copemican  philosophy  of  placing 
the  operator —  not  the  engineer,  not  the  fiscal 
programmer,  not  the  communicator —  at  the 
center  of  the  universe. 


WHAT  IS  A  TADIXS? 

Returning  to  individual  TADIXS,  it  is 
important  to  understand  that  because  of  their 
virtuality,  TADIXS  are  essentially  doctrinal  de¬ 
lineations  of  information  to  and  from  the 
GLOBIXS  ashore  and  from  the  afloat  platforms 
and  sensors  at  sea. 

Like  the  GLOBIXS,  the  TADIXS  should 
be  considered  a  minimal  set,  with  numbers  and 
types  being  a  conscious  reflection  of  command 
structure  and  doctrine.  Thus,  we  should  con¬ 
ceive  of  the  information  flow  from  GLOBIXS  to 
TADIXS  and  back  again  on  the  following  three 
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Figure  6-1.  Anti-Jam  Core  and  General  Purpose  SATCOM 


conceptual  planes,  wMch  we  will  further  de¬ 
velop  into  an  operational  model  later  in  this 
chapter. 

•  First,  the  technological  “envelope”  in  which  the 
data  is  packaged  and  formatted  (e.g.,  GOSIP, 
X.400,  or  CSS  custom  protocols  for  tactical 
application,  which  are  discussed  in  Chapter  8); 

•  Second,  the  operational  data  layering;  that  is,  the 
doctrinal  decision  to  place  the  data  on  a  particu¬ 
lar  TADIXS  and  to  route  the  data  to  a  particular 
commander’s  workstation;  and 

•  Third,  the  transformation  of  data  from  the 
TADIXS  to  information,  which  is  a  function  of 
the  software  interface  on  the  Copemican  tactical 
computers —  the  FASTTs  and  other  “engines.” 

Because  they  are  virtual  and  have  a 
common  engineering  basis,  Copemican  TADIXS 


can  be  likened  to  telephone  calls  over  commer¬ 
cial  network:  the  call  can  be  made  to  anyone  for 
any  purpose  over  any  available  communications 
pathway  for  the  length  of  time  necessary  to 
convey  the  information.  Unlike  telephone  calls, 
Copemican  TADIXS  can  support  all  eight 
formats  of  communications  services  and  in  three 
cases  of  precedence  (see  chap.  3).  However,  like 
telephone  calls,  TADIXS  will  not  have  a  fixed 
connectivity  over  time,  but,  rather,  will  be 
connected  only  for  the  length  of  time  necessary 
to  convey  the  data  to  the  subscribers  and  then 
broken. 

For  these  reasons,  Copemican  TADIXS 
are  classified  in  four  broad  categories —  a  menu 
is  a  good  analogy, —  like  the  GLOBIXS,  by 
“communities  of  interests”  (see  fig.  6-2): 
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•  Command  TADIXS  have  as  their  purpose  both 
high  command  (Le.,  the  connectivity  between 
the  National  Command  Authorities  to  the  tacti¬ 
cal  force  commands  and  the  nodes  in  between) 
and  force  command,  whether  Navy,  joint,  or 
allied  (i.e.,  TADIXS  that  affect  the  command 
and  control  of  tactical  battle  forces  from  the 
tactical  commander  to  his  designated  subordi¬ 
nate —  CWC  to  CWC  commanders  and  units). 
Both  types  of  command  TADIXS  are  envisioned 
as  multiformat,  with  the  former  including 
videoteleconferencing; 

•  The  second  broad  category  are  the  Support 
TADIXS.  In  this  group,  we  includesuchstreams 
as  an  Environmental  TADIXS,  a  Logistics 
TADIXS,  a  Data  Base-File  Transfer  TADIXS, 
an  Imagery  TADIXS,  and  NAVIXS,  which  as 
the  narrative  message  pathway,  is  the  only 
TADIXS  envisioned  to  carry  that  format  All 
other  TADIXS,  including  those  other  than  Sup¬ 
port  are  being  designed  in  formats  other  than 
messages; 


•  The  third  category  of  TADIXS  is  Direct  Target¬ 
ing,  which  will  encompass  several  TADIXS, 
including  a  multisensor  broadcast  that  can  be 
tailored  for  allies  and  filtered  for  geographic  and 
targeting  differences.  Direct  targeting  will  not 
be  further  discussed  in  this  document  and 

*  The  final  category  of  TADIXS  includes  Force 
Operations  TADIXS ,  which  will  be  constructed 
around  the  tactical  force  to  produce  the  informa¬ 
tion  flow  to  answer  the  commander’s  tactical 
questions.  See  figure  6-3.  For  a  CVBG,  for 
example.  Force  Operations  TADIXS  might  be 
expected  (in  addition  to  the  three  categories 
above)  to  include  the  following  TADIXS  for  a 
complex  mission; 

-  The  ASW  Information  Exchange  System 
(ASWIXS),  designed  to  connect  ASW  plat¬ 
forms  to  the  CCC  and  the  ASW  GLOBIXS; 

A  Strike  TADIXS,  set  up  to  provide  consoli¬ 
dated  overland  targeting  products  and  to  con- 
nectStrikeplatforms.theStrike  Warfare  Com¬ 
mander,  and  the  CCC  with  the  several  appro¬ 
priate  GLOBIXS; 
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The  real-time  Links,  including  Joint  Tactical 
Information  Display  System  (JTTDS),  which 
will  be  the  primary  conduits  for  AAW  infor¬ 
mation; 

-  The  Integrated  Special  Intelligence  Commu¬ 
nications  (INSICOM)  TADIXS,  a  series  that 
includes  the  TAC1NTEL,  Intelligence  Net- 
weak  (INTELNET),  Intelligence  Broadcast 
(INTELCAST),  MUSIC/SPECIAL  INTEL-- 
LIGENCE  (SI)  Common,  and  Operational 
Intelligence  (OPINTEL)  functionalities;  and 

A  Space  and  Electronic  Warfare  (SEW) 
TADIXS,  designed  to  connect  the  CCC  SEW 
Center  and  the  SEW  Commander  afloat 


part  of  the  PHASE  n  (see  chap.  10)  Copernicus 
effort,  operational  requirements  for  these 
TADIXS  will  be  refined.  Although  the  number 
of  TADIXS  seems  large  at  first  glance,  it  is 
important  to  understand  that  TADIXS  are  vir¬ 
tual  nets,  established  and  disestablished  by  the 
CW C  and  the  CCC  Watch  as  the  tactical  situa¬ 
tion  demands.  Instantaneous  capacity  will  be  in 
the  hands  of  the  CWC  and  will  be  a  function  of 
how  he  configures  his  radio  frequency  (RF) 
assets,  how  many  and  what  mix  of  TADIXS  he 
chooses  to  establish,  and  the  tactical  situation. 


For  a  JTF  commander,  an  SSN  in  as  so-  TADIXS  BEARER  SERVICES 

dated  support  or  independent  operations,  a  Ma¬ 
rine  Air  Ground  Task  Force  (MAGTF),  or  an  Central  to  Copernicus  requirements  is 

amphibious  task  force,  the  TADIXS  for  Force  the  necessity  for  Navy  to  invest  broadly  across 

Operations  will  be  a  somewhat  different  mix.  As  the  communications  frequency  from  HF  and 
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military  SATCOM  through  commercial  satel¬ 
lite.  Functionally,  Navy  will  continue  to  require 
a  modest  amount  of  the  anti-jam  capability  in¬ 
herent  in  EHF  low  data  rate  (LDR)  SATCOM. 
However,  it  is  anticipated  that  EHF  LDR  will  be 
much  less  common  th  an  medium  data  rate  (MDR) 
EHF;  moreover,  if  technically  feasible,  the  abil¬ 
ity  to  shift  from  MDR  to  LDR  in  a  tactical 
situation  is  highly  desirable. 

Developing  a  virtual  networking 
TADIXS  concept  that  offers  both  jamming  pro¬ 
tection  and  sufficient  communications  capacity 
requires  a  new  approach  to  procuring  and  imple¬ 
menting  Navy’s  communications  assets.  To¬ 
day,  Navy  communications  effectively  are  cen¬ 
tered  on  SATCOM.  Existing  HF  equipment  is 
antiquated,  necessitating  high  manpower  require¬ 
ments  in  return  for  low  data  throughputs.  SHF is 
only  in  adolescent  stages  in  the  Navy,  and  EHF 
availability  and  throughput  will  be  limited.  Com¬ 
mercial  satellite,  like  SHF,  has  the  promise  of 
adding  high  data  rate  capacity  to  the  Navy  afloat 
platforms. 

Four  critical  shortfalls  exist-  today~in . 

Navy  bearer  services.  First,  we  have  not  in¬ 
vested  across  a  broad  range  of  means  from  HF 
systems  through  MILSATCOM  to  commercial 
satellite.  Second,  because  our  current  architec¬ 
ture  is  centered  around  the  message  and  driven 
by  the  sender  and  not  the  receiver,  it  has  proven 
extremely  difficult  to  make  operational  deci¬ 
sions  concerning  information  management 
Third,  we  have  not  engineered  the  means  to 
switch  traffic  from  one  RF  asset  to  another —  a 
key  requirement  in  a  jamming  environment 


Instead,  as  mentioned  previously,  we  have  fo¬ 
cused  on  designing  an  anti-jam  waveform, 
thereby  trading  off  throughput  as  in  Mil  star. 
Fourth,  we  have  never  engineered  virtual  net¬ 
works  that  allow  us  to  use  the  capacity  we  do 
have  efficiently. 

In  the  Copernicus  Architecture,  we  pro¬ 
pose  to  remedy  all  four  shortfalls.  However,  it  is 
importanttaiealize  that  there  are  limits  to  infor¬ 
mation  transfer  capability  in  a  tactical  environ¬ 
ment  What  can  be  done  ashore  in  the  business 
world  over  a  computer-to-computer  fiber  optic 
link  from  Chicago  to  New  York  cannot  be  done 
currently  over  tactical  links  to  sea. 

Moreover,  military  satellite  throughput 
in  the  future  will  not  only  continue  to  lag  behind 
that  of  shore  transmission  media,  butthe  gap  will 
widen  dramatically  as  the  shore  throughput  in¬ 
creases  through  fiber  optics.  Similarly,  the  ship¬ 
board  Local  Area  Networks  (LANs)  will  be 
moving  to  fiber,  also  providing  a  capability  to 
move  very  high  amounts  of  data.  Because  mili¬ 
tary  satellite  capacity  is  limited  and  is  inherently 
less  efficient  than  wire  or  fiber,  the  satellites 
effectively  will  act  as  stoplights  to  the  high¬ 
speed  data  flows  ashore  and  at  sea.  The  same  is 
true  of  non-SATCOM  frequencies  (e.g.,  HF). 
The  trend  toward  fiber  optics  ashore  and  afloat, 
coupled  with  faster  and  faster  computing  capa¬ 
bilities  will  mean  faster  information  manage¬ 
ment  ashore  and  afloat  than  can  be  provided 
between  the  two. 

There  is  no  simple  answer  to  improving 
military  SATCOM  throughput,  limited  as  itis  by 
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the  physics  of  the  spectrum,  the  engineering  of 
the  waveform,  and  the  enormous  expense  of  the 
satellites —  approximately  $  140  million  per  sat¬ 
ellite  for  theNavy  UHF Follow-on  constellation 
(which  is  much  cheaper  than  the  more  complex 
Mils  tar).  However,  it  is  critical  that  the  amount 
of  throughput  of  the  TADIXS  bearer  services 
available  to  us  be  the  absolute  maximum  that  can 
be  achieved.  See  figure  6-4.  To  do  so,  the 
Communications  Working"  Grouptsee‘fntror 
duction),  made  the  following  five  general  re¬ 
quirements,  which  were  approved  by  OP-094. 

First,  the  Navy  must  move  beyond  near- 
total  reliance  on  UHF  SATCOM  to  a  broad 
spectrum  of  means  including  SHF,  EHF,  and 
commercial  satellite  and  improve  our  HF  capa¬ 
bilities  where  appropriate  for  the  architecture. 


The  Copemican  communications  services  shown 
in  Chapter  3  detail  format  requirements.  Figure 
6-5  shows  a  list  of  attributes  by  which  bearer 
services  were  rated  against  formatrequirements. 
Figure  6-6  shows  the  methodology  by  which 
attributes  were  compared  against  bearer  ser¬ 
vices,  using  videoteleconferencing  as  an  ex¬ 
ample  .  In  developing  this  document,  a  similar 
analysis  was  conducted  for  each  format  Figure 
6-7  shows  the  results ‘of  the  analysis. 

Appendix  B  contains  the  report  of  the 
Communications  Working  Group.  Based  on  an 
analysis  of  suitability,  feasibility,  and 
affordability  of  bearer  services  to  implement  the 
architecture,  the  following  strategy  was  devised: 

•  Mils  tar  low  data  rate  and  EHF  on  UHF  Follow- 

on  must  be  deemphasized; 
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Figure  <5-5.  Attributes  for  Rating  of  Bearer  Services 
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Figure  6-6.  Copern ican  Videoteleconferencing  Analysis 
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•  SHF  SATCOM  and  commercial  S  ATCOMmust 
be  accelerated; 

•  UHF  SATCOM  throughput  must  be  increased, 
and  a  plan  must  be  developed  to  do  so; 

•  A  plan  to  incorporate  commercial  satellite  tech¬ 
nically  and  operationally  into  Navy  units  in  the 
Copernicus  Architecture  must  be  developed;  and 

■  A  similar  plan  should  be  developed  for  HF. 


Third,  we  must  use  research,  develop¬ 
ment,  test  and  evaluation  (RDT&E)  to  explore 
better  data  transfer  techniques:  data  compres¬ 
sion,  object-oriented  transmission'  packets, 
“delta”  transmission  (i.e.,  sending  only  the  part 
of  data  files  that  actually  changes  between  trans¬ 
missions).  These  conclusions  mirrored  those  of 
the  Technology  Working  Group  contained  in 
Appendix  A. 


Second,  we  must  overlay  an  operating 
system —  analogous  to  MS-DOS  on  a  personal 
computer  (PC) —  that  will  allow  many  users  to 
efficiently  access  the  capacity  on  the  satellites 
through  dynamic  bandwidth  management  in¬ 
stead  of  dedicated  channels.  This  operating 
system  will  be  manifested  in  the  virtual  net¬ 
working  program  CSS. 


Fourth,  we  must  buy  a  standard  family  of 
workstations  and  file  servers  afloat  with  ever- 
increasing  amounts  of  memory.  Memory  is  far 
cheaper  than  SATCOM  transponders.  The  more 
memory  resident  at  sea,  the  less  data  necessary 
to sendand the smallerthe “delta” for  transmittal 
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Fifth,  we  must  replace  the  many  anti¬ 
quated  communications  processors  with  a  com¬ 
mon  family  of  processors  are  more  efficient,  so 
data  transmission  can  be  accomplished  with  the 
greatest  speed  and  efficiency  possible. 

MANAGING  THE  TADIXS 

TADIXS  management  incorporates  two 
functions:  determining  the  destination  of  spe¬ 
cific  data  on  the  CCC  and  TCC  networks  and 
determining  what  communications  channel  will 
be  used  to  transfer  the  data. 


sion  is  a  distributed  one,  meaning  it  is  made 
within  each  operational  strata  (ie.,  ASW,  AAW, 
SEW).  Thus,  the  SEW  commander  afloat,  by 
delegating  responsibilities  to  the  SEW  anchor 
ashore,  also  makes  information  decisions  at  the 
same  time  as  part  of  the  Copernicus  C*I  deci¬ 
sions  discussed  in  Chapter  3  (see  fig.  6-8). 

Not  onlyisthedecision  distributed  across 
warfare  functions  (which  is  to  say,  how  a.  TADIXS 
will  be  constructed  with  respect  to  what  data, 
how  much,  and  in  what  format  will  be  ex¬ 
changed),  but  it  has  a  temporal  aspect  as  well. 


In  the  Copernicus  Architecture,  the  first 
function  is  a  deliberate  one:  data  may  go  to  one 
destination,  be  shared  by  more  than  one  destina¬ 
tion,  or  not  be  sent  at  all,  at  the  discretion  of  the; 
tactical  commander's  designated  subordinates 
afloat  and  the  CCC  anchors  ashore.  This  deci- 


Temporal  Aspects  Of  TADIXS 

This  temporal  aspect —  how  long  will 
the  “telephone  call”  be —  has  two  facets,  one 
operational  and  one  related  to  engineering. 
Operationally,  the  duration  of  a  TADIXS  has  to 
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do  with  the  mission:  a  decision  to  construct  an  manages  afloat  communications  functions,  and 

ASW  TADIXS  and  keep  it  operative  for  the  the  GLOBIXS  communications  processors, 

duration  of  the  mission1.  which  manage  those  functions  ashore2. 


The  engineering  facet  has  to  do  with 
efficiency —  the  ability  to  sustain  the  ASW 
TADIXS  uninterrupted  in  the  eyes  of  the  ana¬ 
lysts,  while  at  die  same  time  moving  that  TADIXS 
data  and  data  from  other  TADIXS  over  the  same 
communications  channel. — — *—-■ — 

Managing  Communications  Channeling 

The  engineering  consideration  as  to  effi¬ 
ciency  of  data  “bundling”  is  an  integral  part  of 
TADIXS  communications  channeling,  the  sec¬ 
ond  function  of  TADIXS  management  Unlike 
the  information  management  function,  this  func¬ 
tion  is  not  distributed.  Afloat  the  responsibility 
will  be  delegated  by  the  CINC  to  the  SEW 
commander,  who  will  exercise  it  through  one  of 
his  principal  assistants,  the  staff  communicator. 
Ashore,  this  function  will  belong  to  the  SEW 
center  (or  other  organization  designated  by  the 
Fleet  CINQ,  where  the  operational  (ie.,  infor¬ 
mational)  decisions  of  the  CCC  anchors  and 
tactical  commander  and  the  communications 
decisions  (i.e.,  data  management)  to  implement 
them  take  place. 

The  technological  means  to  achieve  this 
interface  will  be  through  the  CSS  system,  which 


1  An  alternative,  for  example,  might  be  a  5 -minute  TADIXS 
constructed  to  place  a  vendor  laboratory  computer  in  dialog  for 
on-line  diagnostics  with  automated  test  equipment  modules 
embedded  in  die  vendor's  equipment  installed  on  a  ship. 


The  delineation  of  formats  and  prece¬ 
dences  of  data  arising  from  the  GLOBIXS  will 
be  accomplished  technically  through  the 
GLOBIXS  processor  software,  which  will  imple¬ 
ment  the  “toggling”  instructions  of  the  respec- 
tive-  CCC  anchor;  who  is  in  turn  implementing 
his  serviced  tactical  commanders’  instructions. 
Afloat,  the  processing  software  for  a  TCC  posi¬ 
tion  would  also  reflect  the  doctrinal  decision  of 
the  tactical  commander.  In  this  way,  by  format 
and  precedence,  the  CCC  anchors  and  their 
counterparts  afloat  define  the  TADIXS  opera¬ 
tionally. 

On  a  communications  level,  then,  the 
communicators  bundle  the  data  from  afloat  plat¬ 
form  to  afloat  platforms  and  ashore  to  the  CCC 
in  the  most  efficient  manner  through  the  CSS 
controller  managed  from  TCC.  In  practice,  to 
the  operator,  the  TADIXS  will  seem  a  constant 
connection  for  the  duration  of  the  TADIXS 
“telephone”  call,  perhaps  better  termed  “ses¬ 
sion.”  Similarly,  in  practice,  the  CSS  automati¬ 
cally  will  manage  the  communications  path¬ 
ways  until,  in  a  tactical  situation,  the  amount  of 
capacity  is  insufficient  to  meet  the  operational 
requirements  of  the  commander.  In  that  in¬ 
stance,  the  decision  is  an  operational  decision 


2  The  delineation  between  the  two  processors  is  a  technological 
one.  The  technological  requirements  to  move  GLOBIXS  data 
ashore  over  DCS  and  TADIXS  data  afloat  through  CSS  and  the 
tactical  RF  infrastructure  differ  because  the  standard  and  proto¬ 
cols  of  the  two  differ. 
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made  by  the  commander,  not  by  the  communica¬ 
tor3. 

It  is  important  to  note  there  are  other 
methods  by  which  the  tactical  commander  can 
choose  his  data  than  the  one  we  have  just  de¬ 
scribed,  although  that  will  be  die  more  typical 
case.  However,  the  Direct  Targeting  TADIXS 
may  employ  a  different  approach  because  of 
efficiency  gained  by  doing  so.  Instead  of  the 
tactical  commander  determining  what  data  will 
be  sent  from  shore  to  him,  in  Direct  Targeting, 
the  more  efficient  means  may  be  to  broadcast  the 
information  to  all  tactical  units  and  allow  the 


3  The  reader  should  bear  in  mind,  however,  that  in  this  architec¬ 
ture,  several  major  advantages  are  conferred  that  will  add  capao 
ity  beyond  that  available  today.  First,  and  obviously,  we  will 
invest  in  more  capacity  across  the  spectrum.  Second,  most  of  die 
data  transferred  will  be  digital,  not  character-oriented,  with  a 
resultant  system- wide  efficiency  in  throughput.  Third,  virtuality 
maximizes  die  capacity  that  is  available. 


commander  to  “dial  in”  on  what  he  wants.  The 
output  and  nature  of  some  sensor  TADIXS  may 
make  this  approach  useful. 

A  TADIXS  MODEL 

Five  elements  define  any  TADIXS  (see 
fig.  6-9).  Using  those  elements,  we  can  construct 
a  model  of  a  SEW  TADIXS,  much  in  the  same 
manner  that  the  tactical  commander  would  acti¬ 
vate  that  TADIXS  in  execution  of  a  mission 
using  the  architecture. 

The  first  element  of  a  TADIXS  is  user 
software  (i.e.,  the  FASTT  Human-Machine  In¬ 
terface  [HMI])  and  data  addressing.  In  the  case 
of  this  SEW  TADIXS,  the  SEW  HMI  would 
provide  C4!,  electronic  warfare  (EW),  surveil- 
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Figure  6*9.  Five  Elements  of  a  Model  TADIXS 
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lance  and  C*I  counter  measures  tools.  To  del¬ 
egate  responsibilities  further,  the  SEWC  may 
opt  to  send  data  relative  to  blue  force  communi¬ 
cations  to  one  FASTT  operated  by  the  staff 
communicator  and  the  remaining  data  to  the  a 
secondFASTT  operated  by  the  staff  cryptologist 

By  this  division,  the  SEWC  has  decided 
to  delegate  his  responsibilities  into  two  pieces:  a 
“blue”  SEW  position  displaying-information — 
about  his  own  assets  and  their  vulnerability,  and 
a  “red”  position  displaying  the  known  (and  un¬ 
known)  similar  information  about  the  enemy. 

The  second  element  is  the  decision  to 
define  the  data —  the  communication  service — 
to  be  sent  over  the  TADIXS  in  terms  of  format 
(e.g.,  voice,  video,  COPCOM). 

The  third  element  is  to  define 
subscribership  and  the  terms  of  subscribership. 
This  element  is  part  of  the  process  of  “toggling” 
the  GLOBIXS,  but  it  is  important  to  recognize 
there  is  a  need  to  “toggle”  other  TADIXS  sub¬ 


scribers  on  the  net  as  well.  In  other  words,  the 
tactical  commander  can  send  what  communica¬ 
tions  service  must  be  established —  by  prece¬ 
dence  as  well  as  format 

The  fourth  element  is  duration.  In  this 
case,  we  will  establish  the  TADIXS  as  a  “perma¬ 
nent”  TADIXS,  which  is  to  say  that  it  is  on  line 
for  the  duration  of  the  mission  as  opposed  to  a 
distinct  *-time-  frame  like  a  one-hour  date,  file 
transfer  or  the  vendor  test  equipment  TADIXS 
described  previously. 

The  final  element  is  the  communications 
pathway.  This  decision,  made  by  the  staff  com¬ 
municator  through  the  CSS  controller,  is  a  func¬ 
tion  of  available  path,  data  format,  degree  of 
jam-resistance  required,  the  capabilities  of  other 
TADIXS  subscribers,  and  the  duration  of  die 
TADIXS. 

In  the  next  chapter,  we  will  discuss  the 
final  pillar  of  the  architecture,  the  Tactical  Com¬ 
mand  Center. 


RELATED  PROGRAMS 

Advanced  Narrowband  Digital  Terminal  (ANDVT):  A  secure  digital  voice  or  data  traffic  device  for  use  over  narrowband 
voice  frequency  channels  on  aircraft,  ships,  or  land  vehicles. 

Classic  Lightning  (formerly  Navy  Key  Distribution  System — NKDS):  This  program  is  described  in  Chapter  4. 

Combination  Radio  (COMBO  RADIO):  Designated  the  AN/ARC-210,  it  provides  anti-jam  (voice)  communications  in 
the  UHF  and  very-high  frequency  (VHF)  portions  of  the  spectrum.  The  primary  application  is  for  AAW  and  close  air  support 
(CAS)  operations.  It  is  applicable  to  the  F/A-18,  the  AF-8B,  F-14D,  E-2C,  EA-6B,  AH-1,  CH-53,  UH-1N,  OV-IO,  and  EP- 
3.  It  promotes  interoperability  with  Departmentof  Defense  (DOD)  and  allied  HAVEQUICK  AND  Single  Channel  Ground 
to  Air  Radio  System  (SINCGARS). 
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HAVEQUICK:  A  UHF  LOS  frequency-hopping,  jam-resistant  communications  system  developed  by  the  Air  Force  for 
tactical  voice  applications.  It  is  provided  as  an  applique  to  existing  radios  used  by  the  various  Services  and  some  North 
Atlantic  Treaty  Organization  (NATO)  allies.  In  the  Navy,  it  is  used  with  the  AN/WSC-3,  and  the  AN/ARC-182. 
HAVEQUICK  HA  is  the  NATO  standard. 

High  Speed  Fleet  Broadcast  (HSFB):  The  HSFB  is  comprised  of  individually  encrypted  broadcast  packages  generated  from 
multiple  user  subsystems.  Multiplexing  of  the  subsystem  outputs  enables  sharing  of  available  gatp.llire  capacity  and  at  the 
same  time  allows  flexibility  in  altering  bit  rates  in  response  to  varying  operational  needs  and  environments.  HSFB  is 
transmitted  through  the  OM-5 1  spread-spectrum  modem  and  the  AN/FSC-79  terminal  and  through  broadcast  keying  and  re¬ 
keying  sites  for  HF.  Mobile  platforms  receive  the  HSFB  via  the  modified  AN/SSR-1  satellite  communications  broadcast  or 
theHF  receiver  in  conjunction  with  an  NDI  modem  using  serial  tone  modulation  techniques  in  accordance  with  MIL-ST 1 88- 

Joint  Tactical  Information  Distribution  System  and  Multifunctional  Information  Distribution  System  (JTIDS/ 

MIDS):JTIDSisaprogram  to  provide  selectedair.seai,  and  ground  units  withacrypto-secure,  jam-resistant,  low-probability- 

of  exploitation  tactical  data  and  voice  communications  system.  It  will  have  the  additional  capabilities  of  common-grid 
navigation  and  the  use  of  automatic  relay.  MIDS  is  a  pre-planned  product  improvement  (P3I)  of  the  JTIDS  Class  2  terminal. 
As  such,  it  will  utilize  the  Link-16  message  standard  and  will  be  applicable  to  the  F/A- 18  and  E-2C.  MIDS  offers  a  substantial 
reduction  in  size  as  compared  to  the  Class  2  terminal. 


Link  Eleven  Improvement  Program  (LEIP):  A  program  designed  to  improve  existing  Link  1 1  high-speed,  computer-to- 
computer  digital  radio  communications  in  the  HF  and  UHF  bands  among  Combat  Direction  System  (CDS)  eauiooed  shins 
submarines,  aircraft,  and  shore  sites. 

High  Frequency  (HF)  radio:  An  existing  capability  for  plain  and  secure  voice,  plain  and  secure  teletypewriter,  and  secure 
data  information  exchange.  Modernization  programs  in  planning  include  the  HF  modem  replacement  (HFMR)  and 
broadband  HF  (AN/URC- 109)  programs  for  specific  ship  types. 

Navy  Intelligence  Processing  System  (NIPS):  A  program  to  update  the  hardware  and  software  used  on  flagships.  The 
program  will  upgrade  from  a  mini-computer  base  to  distributed  workstation  processing. 

Navy  Standard  Teleprinter  (NST):  A  program  to  replace  outdated  teletypes  (TTYs)  with  the  UGC-143A(V)  teleprinter. 
The  new  item  is  modular  and  can  be  configured  in  four  versions  (receive  only,  receive  only  with  bulk  storage,  keyboard  send/ 
receive,  auto  send/receive).  Installation  on  ships  began  in  FY91. 

Officer  in  Tactical  Command  Information  Exchange  Subsystem  H  (OTCIXS):  A  Demand  Assigned  Multiple  Access- 
(DAMA)  capable  tactical  satellite  communications  network  for  command  and  control  of  Battle  Group  operations  and  ship- 
to-ship,  ship-to-shore,  exchange  of  data  link  and  teletype  information.  It  is  to  provide  dependable  beyondline  of  sight  (BLOS) 
communications  between  surface,  sub-surface,  and  share  installations  on  a  near-real-time  back 

Super  High  Frequency  (SHF)  SateDite  Communications  for  Aircraft  Carriers  (CV)  and  Flagships:  The  only  ships  that 
currently  have  capability  to  use  Defense  Satellite  Communication  System  (DSCS)  SHF  SATCOM  are  the  numbered  fleet 
commander  flagships.  The  SHF  SATCOM  for  CV/Flagships  program  will  expand  this  capability  to  aircraft  carriers  and  other 
ships  designated  as  being  capable  of  supporting  an  embarked  flag  officer.  The  operational  service  to  be  provided  is  being 
determined.  At  a  minimum,  the  capability  will  be  similar  to  existing  AN/WSC-6(V)2,  providing  approximately  9600  bps 
capacity  in  a  benign  electronic  combat  environment  Alternative  capabilities  that  could  enable  higher  data  rates  are  under 
consideration. 

Super  High  Frequency  (SHF)  SateDite  Communications  (SATCOM):  An  existing  Navy  program  that  provides  AN/ 
WSC-6(V)  1  capability  for  Surface  Towed  Array  Surveillance  System  (SURTASS)  and  AN/WSC-6(V)2  for  Numbered  Fleet 
Commander  flagships.  The  SURTASS  system  has  no  anti-jam  capability  and  operates  at  64  kbps  in  a  benign  anti-jam 
environment.  The  combatant  ship  system  (AN/WSC-6(V)2  with  OM-55  anti-jam  modem)  operates  at  a  nominal  maximum 
of  32  kbps  (actual  rate  is  between  22,000 bps  and  4,800  bps)  in  a  benign  electronic  combat  environment,  and  degrades  to  75 
bps  in  a  moderately  severe  electronic  combat  environment 
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Submarine  Satellite  Information  Exchange  System  (SSIXS II):  SSIXS  provides  a  means  to  use  the  UHF  FLTS  ATCOM 
system  for  a  4800  bps,  two-way  exchange  of  text  messages  between  shore-based  Submarine  Operating  Authorities 
(SUBOPAUTHs)  and  submarines,  and  between  submarines.  SSIXS  II  is  a  system  block  upgrade  that  replaced  the  AN/UYK- 
20  processor  hardware  and  software  in  shore  sites  with  commercial  off  the  shelf  (COTS)  hardware  and  Ada  software. 

Integrated  SI  Communication  (INSICOM):  This  program  supports  Sensitive  Compartmented  Information  (SCI) 
exchange  requirements  in  support  of  AAW,  ASUW,  STW,  ASW,  and  Amphibious  Warfare  (AMW)  operations.  It  will 
operate  on  HF,  UHF  LOS,  and  on  UHF,  SHF,  and  EHF  SATCOM  simultaneously  or  any  mix  of  those  systems.  INSICOM 
provides  capabilities  previously  expressed  by  the  INTELCAST  and  INTELNET  programs.  It  will  be  capable  of  netted,  point- 
to-point,  or  broadcast  communications,  and  INTELCAST  will  support  many  information  exchange  formats. 

Tactical  Receive  Equipment  (TRE)  (TADIXS  B/TRE):  An  all-Service  program  to  provide  for  the  collection,  processing, 
and  timely  broadcast,  via  UHF  SATCOM  down  link,  ofhighly  accurate  positional  and  parametric  contact  data.  The  AN/USQ- 
101  (V)  is  the  equipment  suitefor  RF  reception,  processing,  and  delivery J>f-the  data,  to  userbaseband  equipment.  TRE 
operates  at  2400, 4800,  or 9600  bps  and  can  receive  signals  with  or  without  forward  error  coding  up  to  19.2kbps.  There  are 
six  configurations  (Army,  Air  Force,  United  States  Marine  Corps,  Navy  ship.  Navy  submarine.  Navy  shore). 

UHF  Follow-on  (UFO)  Satellite  Communications  Program:  UFO  is  a  program  to  procure  replacements  for  the 
FLTS  ATCOM  satellites.  A  constellation  of  nine  (including  one  on-orbit  spare)  is  envisioned.  The  satellites  will  provide  39 
mmmnnieaHnns  channels  and  will  utilize  SHF  telemetry  and  command  signals.  Launch  will  be  via  either  the  shuttle  or 
expendable  vehicles.  Initial  Operational  Capability  (IOC)  IQ  FY92. 

UHF  Line  of  Sight  (LOS):  UHF  LOS  radios  are  used  for  voice  and  data  (primarily  Link  11)  information  exchange  among 
fleet  units.  Voice  may  be  either  clear  or  encrypted,  with  VINSON  (KY -57/KY -58)  used  for  on-line  encryption.  All  fleet  units 
have  some  UHF  LOS  capability.  Only  air  warfare  ships,  submarines,  and  some  aircraft  have  UHF  LOS  Link  1 1.  Ships  use 
secure  teletype  (KG-84A  or  KG-84C)  via  UHF  LOS  for  intra-Battle  Group  message  exchange  when  within  UHF  LOS  range 
(approximately  30  nm).  UHF  LOS  equipment  is  predominantly  the  AN/WSC-3.  Most  UHF  LOS  equipment  has  no  anti¬ 
jam  capability,  but  the  HAVEQUICK  frequency-hopping  applique  is  being  provided  for  combat  aircraft  and  for  primary  air 
control  ships  that  communicate  with  combat  aircraft 

UHF  Satellite  Communication  (SATCOM):  UHF  SATCOM  is  used  for  voice  and  data  information  exchange  among  fleet 
units.  Most  combatants  have  at  least  one  Demand  Assigned  Multiple  Access  (TD-1271 DAMA)  unit  to  multiplex  as  many 
as  four  user  information  streams  (at  4800  bps  or  lower)  into  one  carrier  frequency  up/down  link.  Voice  is  covered  by  one 
of  four  voice  encryption  systems:  1)  CV-3333  Narrowband  Secure  Voice  with  KG-30  series  COMSEC,  2)  Advanced 
Narrowband  Digital  Voice  Terminal  (ANDVT,  in  the  AN/USC-43  configuration  that  is  replacing  CV-3333),  3)  Parkhill  (KY - 
65orKY-75),and4)  VINSON (KY-57orKY-58).  Datacapability  includes  secure  teletype  (KG-84AorKG-84C  COMSEC) 
and  the  automatic  information  exchange  systems  listed  below.  All  combatants  have  some  UHF  SATCOM  capability.  UHF 
SATCOM  radios  afloat  are  the  AN/WSC-3.  The  AN/WSC-5  is  the  principal  radio  for  use  ashore.  Portable  radios  (AN/PSC- 
3  or  AN/URC-110)  are  used  for  special  operations  or  (in  some  cases)  to  provide  a  special  capability  for  a  ship.  Current 
automatic  information  exchange  systems  that  operate  via  UHF  SATCOM  include: 

•  Officer  in  Tactical  Command  Information  Exchange  System  (OTCIXS); 

•  Tactical  Data  Information  Exchange  System  (TADIXS  A); 

•  Tactical  Intelligence  information  exchange  system  (TACINTEL); 

•  Fleet  Imagery  Support  Terminal  (FIST); 

•  Common  User  Digital  Information  Exchange  System  (CUDIXS);  and 

•  Submarine  Information  Exchange  System  (SSIXS). 

Very  High  Frequency  (VHF)  Radio  Systems:  Navy  uses  VHF  radios  for  1)  communication  with  Air  Force,  Army,  and 
allied  aircraft,  2)  coordination  of  naval  gun  fire  support  (NGFS),  and  3)  control  of  landing  craft  and  boats.  Conventional  VHF 
radios  (AN/VRC-46)  are  used  primarily  for  encrypted  voice  service,  using  the  VINSON  (KY -57  or  KY -58)  COMSEC.  The 
Single  Channel  Ground  and  Air  Radio  System  (SINCGARS)  is  a  VHF  system  that  provides  anti-jam  service  and  is  capable 
of  communicating  either  voice  or  data. 
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CHAPTER  7 

TACTICAL  COMMAND  CENTER  (TCC) 


SUMMARY 

:§||;j|||||:Thftf!nal  pillar  of  the  Copernicus  Architecture  is  the  Tactical  Command  Center  (TCC);;  used  in  this  architecture 


Command  Center  (TFCC)  program .  In  the  Copernicus  Architecture,  the  TCC  is  intended  to  signify  the  combat  “nerve 
centers’*  of  the  tactical  commander  and  his  units.  Thus,  TCC  in  Copernicus  means  not  only  the  TFCC,  CTC,  CVIC, 
SUPPLOT,  and  SSESl  in  an  aircraft  carrier  or  analogous  centers  on  a  fleet  flagship,  but  also  the  tactical  centers  for 
individual  units  and  the  command  centers  for  multi-force  commanders  such  as  the  Marine  Air  Ground  Task  Force 
(MAGTF)  and  joint  task  force  (JTF). 


The  TCC  provides  the  tactical  displays,  integrated  information  management,  and  accessibility  to  tactical 
communications  to  support  Navy  warfighting  missions.  It  provides  the  requisite  battle  connectivity  to  units,  other  force 
commanders,  and  the  Commander  in  Chief  Command  Complex  (CCC).  Architecturally,  the  TCC  is  analogous  to  the 
ashore  command  center,  the  CCC.  Both  will  share  a  consistent  tactical  picture  and  connect  the  Navy  to  the  Services  and 
to  allies —  at  the  tactical  level  and  the  theater  level. 

TCC  in  the  Carrier  BattleGroup  (C  VBG)context  means  the  creation  ofperiodic  and  aperiodic  local  area  networks 
(LANs)  afloat.  Until  multi-level  security  is  achieved,  separate  Special  Intelligence  (SI)  and  "General  Service"  (GENSER) 
LANs  will  be  required.  With  the  establishment  of  fiber  optic  busses  afloat —  the  ship’s  “information  highway” —  the  LAN 
connectivity  will  also  become  virtual  and  fall  into  two  broad  categories. 

The  first  category  is  the  periodic  LAN,  which  handles  time  critical  and  continuously  updated  information.  The 
second  type  is  aperiodic  where  data  is  not  time  critical  and  is  updated  at  various  intervals  These  LANs  will  have  high 
bandwidth  and  provide  high  speed  connectivity  for  all  the  TCC  spaces,  encompassing  on  a  carrier  for  example,  CVIC, 
SUPPLOT,  SSES,  and  TFCC  proper  as  well  as  the  ships  decision  centers. 


Tactical  Terminal  (FASTT)  workstations  ( with  application  specific  software)  and  receive  data  from  various  TAD1XS. 
The  LANs  will  be  supported  by  various  utilities  and  servers  providing  high  speed  message  search  retreival.  E-mail,  and 
other  common  user  functions. 

The  CVBG  TCC  will  incorporate  the  functionality  of  several  formerly  separate  tactical  C4!  systems.  As  we  have 
seen,  FASTTs  are  application  “engines”  with  high  percentages  of  common  commercial  off-the-shelf  (COTS)  and 
government  off-the-shelf  (GOTS)  software.  The  shared  utilities  (data  bases,  operating  systems,  etc.)  will  be  resident  in 
,  various  servers  available  to  all.  The  use  of  a  FASTT  for  a  tactical  mission  is  achieved  through  a  veneer  of  software 
application  aimed  at  the  warfare  mission.  11108,  the  difference  between  an  Anti-Air  Warfare  (AAW),  Anti-Submarine 
Warfare  (ASW),  Space  and  Electronic  Warfare  (SEW),  and  Anti-Surface  Warfare  (ASUW)  FASTT  is  the  mission- 
software  installed  over  the  95-percent  common  FASTT  and  supported  by  common  utilities. 

1  Combat  Information  Center  (CIC),  Carrier  IntclligenceGenter(CVIC),  Supplementary  Plot  {SUPPLOT),  and  Ship  Signals  Exploitation 
Space  (SSES). 
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Using  the  FASTTs  and  the  LAN  concept,  the  tactical  commanderachieves  an  agility  in  constructinghis  command 
and  control  that  heretofore  was  not  possible.  The  final  ingredient  is  the  virtual  TADIXS  mix  which,  when  shunted  onto 
theL  ANs  to  the  diverse  FASTTs,  allows  the  Officer  in  Tactical  Command  (OTC)/Compositc  Warfare  Commander  (CWC) 
to  actually  configure  his  command  and  control  system  to  his  tactical  doctrine  to  suit  the  mission. 

As  we  saw  in  Chapter  5,  the  command  and  control  processes  of  planning,  assessing,  observing,  executing,  and 
reporting  are  structured  with  respect  to  command  level.  Differences  are  evident:  in  attributes:  timeliness  of  processing, 
level  of  hierarchical  view  of  die  problem  (global,  theater,  scene  of  action),  and  volumes  of  information  stored,  retrieved 
and  processed.  A  broad-  range  of  computational  capabilities:  :arc  also  common  across :  command  levels:  arithmetic, 
geometric,  statistics/probabilities,  and  conversions.  These  and  other  types  of  commonalties  suggest  that  at  equal  command 
levels,  there  will  be  a  high  degree  of  commonalty  in  required  system  functions.  At  other  levels  in  the  hierarchy,  there  is 
still  a  high  degree  of  commonalty,  but  less  than  that  found  between  equal  levels. 

Considerations  suchas  these  become  evident  in  the  similarities  between  this  chapter  and  Chapters,  which  relates 
to  the  CCC.  This  commonality  suggests  thata  modular  design  for  both  CCCandTCC  configuration  is  a  rational  approach. 
Common  database  structures,  dictionaries,  andmanagement  techniques  are  possible  as  are  common  application  programs, 
display  generators  and  displays,  and  communications  interface  and  processing  algorithms,  all  contributing  to  consistent 
data  base  fill.  These  attributes  of  commonalty  and  modularity  ,  while  allowing  for  unique  applications  tailored  to  warfare 
mission  area  and  command  level,  are  characteristics  of  the  Copernicus  concept.  Chapter  8  presents  an  engineering  model 
of  CCC  and  TCC  and  states  requirements  for  CCC  and  TCC. 


DISCUSSION 

The  final  pillar  of  the  Copernicus 
Architecture  is  the  TCC,  used  in  this  architec¬ 
ture  in  a  much  broader  sense  than  conveyed  in 
the  past  with  the  existing  platform-specific 
programs,  such  as  the  TFCC  program.  In  the 
Copernicus  Architecture,  the  TCC  is  intended 
to  signify  the  combat  “nerve  centers”  of  the 
tactical  commander  and  his  units.  Thus,  TCC 
in  Copernicus  means  not  only  the  TFCC,  CIC, 
CVIC,  SUPPLOT,  and  SSES  in  an  aircraft 
carrier  or  analogous  centers  on  a  fleet  flag¬ 
ship,  but  also  the  tactical  centers  for  indi¬ 
vidual  units  and  the  command  centers  for 
multi-force  commanders  such  as  the  MAGTF 
and  JTF. 

The  TCC  provides  the  tactical  displays, 
integrated  information  management,  and  acces¬ 


sibility  to  tactical  communications  to  support 
Navy  warfighting  missions.  It  provides  the 
requisite  battle  connectivity  to  units,  other  force 
commanders,  and  to  the  CCC.  Architecturally, 
the  TCC  is  analogous  to  the  ashore  command 
center,  the  CCC.  Both  will  share  a  consistent 
tactical  picture  and  connect  the  Navy  to  the 
Services  and  to  allies —  at  the  tactical  level  and 
the  theater  level. 

TCC  in  the  CVBG  context  means  the 
creation  of  periodic  and  aperiodic  LANs  afloat. 
Until  multi-level  security  is  achieved,  separate 
SI  and  GENSER  LANs  will  be  required.  With 
the  establishment  of  fiber  optic  busses  afloat — 
the  ship’s  “information  highway” —  the  LAN 
connectivity  will  also  become  virtual  and  fall 
into  two  broad  categories. 
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The  first  category  is  the  periodic  LAN, 
which  handles  time  critical  and  continuously 
updated  information.  The  second  type  is 
aperiodic  where  data  is  not  time  critical  and  is 
updated  at  various  intervals.  These  LANs  will 
have  high  bandwidth  and  provide  high  speed 
connectivity  for  all  the  TCC  spaces,  encompass¬ 
ing  on  a  carrier  for  example,  CVIV,  SUPPLOT, 
SSES,  and  TFCC  proper  as  well  as  the  ships 
decision  centers. 

These  information  LANs  will  be  charac¬ 
terized  by  different  protocols  but  will  operate 
Copemican  Fleet  All  Source  Tactical  Terminal 
(FASTT)  workstations  (  with  application  spe¬ 
cific  software)  and  receive  data  from  various 
TAD1XS.  The  LANs  will  be  supported  by 
various  utilities  and  servers  providing  high  speed 
message  search  retreival.  E-mail,  and  other  com¬ 
mon  user  functions. 

The  CVBG  TCC  will  incorporate  the 
functionality  of  several  formerly  separate  tacti¬ 
cal  C4I  systems.  As  we  have  seen,  FASTTs  are 
computing  “engines”  with  high  percentages  of 
common  COTS  and  GOTS  (i.e.,  owned  and 
developed  by  the  Government  for  broad  applica¬ 
tions,  such  as  algorithms)  software.  The  use  of 
a  FASTT  for  a  tactical  mission  is  achieved 
through  a  veneer  of  software  application  aimed 
at  the  warfare  mission.  Thus,  the  difference 
between  an  AAW,  ASW,  SEW,  and  ASUW 
FASTT  become  the  mission-software  installed 
in  the  95-percent  common  FASTT. 


in  construction  of  his  command  and  control  that 
heretofore  was  not  possible.  The  final  ingredi¬ 
ent  is  the  virtual  TADIXS  mix  which,  when 
shunted  onto  the  LANs  to  the  diverse  FASTTs, 
allows  the  CWC  to  actually  configure  his  com¬ 
mand  and  control  technology  to  his  tactical 
doctrine  to  suit  the  mission. 

Copernicus  then,  provides  the  CW C  with 
the  following  unique  capabilities: 

•  The  TCC  can  be  configured  and  reconfigured 
quickly  to  suit  the  changing  tactical  situation; 

•  The  high-technology  FASTT  can  assimilate,  sort, 
and  display  large  amounts  of  sensor  reports,  data 
files,  and  imagery  onto  a  warfare  specific  "ve¬ 
neer"  software —  making  the  notion  of  isolated 
imagery  or  data  files,  now  placed  in  the  context 
of  the  mission-analytics  and  fed  onto  the  LAN 
through  the  TADIXS,  obsolete; 

•  The  construction  of  virtual  TADIXS  in  common 
formats —  an  ASW  sensor  report  in  the 
Copernicus  Architecture  is  formatted  identically 
to  an  Electronic  Intelligence  (ELINT)  report — 
allows  the  CWC  to  make  decisions  about  which 
subordinates  receive  which  data,  when,  and  how; 

•  The  advent  of  the  CSS  workstation  allows  the 
CWC  to  determine  which  information  is  pro¬ 
tected  by  the  core  of  anti-jam  media  and  which  is 
not  and,  thus,  he  is  provided  both  reliability  and 
efficiency  by  his  own  choice;  and 

•  The  CCC,  through  the  addressing  of  data  packets 
and  the  configuration  of  the  Global  Information 
Exchange  System  (GLOBIXS)  nodes  tailored 
for  each  tactical  commander  can  act  as  facilitator 
or  filter  or  both,  as  the  CWC  directs. 


Using  the  FASTTs  and  the  LAN  con¬ 
cept,  the  tactical  commander  achieves  an  agility 


7-4  •  Tactical  Command  Center  (TCC) 


A  MODEL  TCC 

The  TCC  receives  information  via  the 
TADIXS,  maintains  data  bases  and  tactical  plots, 
and  transmits  information  to  forces  afloat  and  to 
the  CCC  ashore.  It  is  the  echelon  where  organic 
tactical  information,  non-organic  tactical 
information,  and  combat  support  information 
are  fused  to  provide  a  clear,  coherent  tactical 
picture.  Figure  7-1  and  box  text  7- 1  illustrate  the.. 
Copemican  TCC  concept. 

While  the  goal  of  the  Copernicus  Archi¬ 
tecture  is  to  move  all  Navy  and  Marine  Corps 
nerve  centers  into  a  flexible  building  block  TCC 
model,  it  is  recognized  this  will  be  an  evolution¬ 
ary  process.  At  this  writing,  the  TCC  is  closest  to 
implementation  in  the  five  flag-configured  ships 


(see  next  paragraph),  and  we  will  confine  our 
model  to  those.  Phase  II  of  the  Copernicus  effort 
(see  chap.  10)  will  seek  to  define  Copemican 
models  for  other  command  and  control  nodes 
(e.g.,  the  SSN,  MAGTF)  through  working  groups 
comprised  of  personnel  with  experience  in  these 
areas. 

The  TCC  model  is  comprised  of  com¬ 
puter-based  TCC  subsystems  located  in  five 
classes  of  flag-configured  ships:  LCC,  AGF, 
CV/CVN,  LHD,  and  CG/CGN.  The  LHA  class 
is  also  a  candidate  TCC  platform.  Within  these 
ships,  TCC  subsystems  are  connected  by  Local 
Area  Networks  (LANs).  Subsystems  are  con¬ 
nected  to  flagship  systems  (e.g..  Advanced  Com¬ 
bat  Direction  System  [ACDS])  via  network  gate¬ 
ways.  Network  gateways  provide  control  and 
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Boxed  Text  7-1.  Conceptual  TCC 


The  Copernicus  model  of  theTCGnecessarily 
simplifies  the  coraplexitiesinherentih  the  commandand 
control  structure  of  the  modern  baulefojrcei  Phase  Hof 
Copernicus  implementation  wdl  expand  the  concept  of 
theTCCand  its  supportingTAbixSto  account  for  this 
5«^plexity:|[see  figs.  7%1  ;  1  and  Jhere  ape  ;sSei 

guiding  principles  for  implementing  the  TCC: 

•  The  TCC  is  a  command  and  control  node 
supportingaparticularwarfightingcommander. 

;  A  warfighting  commander  can  be  the  CWC/"4"' 
%  Oft,  the  AAWC,  theSEWC,a  landingforce  . 
commander  ashore,  or  the  commander  of  a 
ship/aircraft.  The  TCC  is  not  defined  by  the 
: ;  platform/space  in  which  the  commander  sits, 
but  rather  by  the  warfighting  functions  he/she 
performs; 


TADIXS 
from  CCC 


Ccwc 

TCC  J 


INTRA  BATTLE  GROUP 


The  TCC  is  defined  by  the  warfighting  func- 
:  tions  of  the  commander  rather  than  die  mission 
culpabilities | if  aplitfanili  C#ernic^s  does 
away  with  the  conventional  notion  of  the  “flag 
cinfigiired”pktfoiit^m  lav®  I 


platforms  have  some  capability  to  support  a 
warfi|htmg  con^  more 

than  others.  All  platforms  with  the  necessary 


tactical  picture.  Platform  design  should  con- 


rather  than  being  “flag  configured”; 


TADIXS 
to  CCC 


Node  TADIXS  Capacity 


I - n 

sJTRA  BATTLE  GROU 

p - 1 

INTRA  BATTLE  GROUP 


Width  =  Amount  of  Information  on  TADIXS 
Total  Width  =  Total  TADIXS  Capacity 


Figure  7B-1.1.  TCC  Information  Flow 


7-6  •  Tactical  Command  Center  (TCC) 


A  TCC  can  support  only  one  warfighting  com¬ 
mander  atatime  (since  the  TCC  functionality  is 
specified  by  the  commander  for  a  particular 
mission  or  partofamission,  more  than  one  TCC 
can  be  implemented  on  a  given  platform,  in  a 
given  space,  depending  on  the  C4I  hardware/ 
software  resources  available; 

Conversely,  a  TCC  (as  well  as  a  CCQ  can  be 
distributed  among  more  than  one  platform  at  a 
time(e.g.,  the  TCC  of  the  Landing  Force  Com¬ 
mander  after  an  assault  but  before  command 
has  passed  ashore).  Another  example  of  a 
distributed  TCC  is  one  constituted  by  a  JTF 
commander  whochooses  to  remain  ashore  (e.g., 
at  the  American  Embassy)  while  using  the  com¬ 
mand  and  control  capabilities  of  a  Navy  ship 
present  to  support  an  evacuation; 


TADIXS  are  virtual  networks  connecting  TCCs 
with  each  other  and  with  the  CCC.  Based  on 
the  previous  discussion,  TADIXS  are  not  lim¬ 
ited  to  RF  bearer  services.  In  some  biases  they 
may  be  implemented  using  intraplatform  IC 
bearer  services;  and 

TCCs  are  implemented  hierarchically  in  con¬ 
sonance  With  the  command  structure:  imposed 
for  a  given  mission.  All  TCCs  cannot  have 
unlimited  and  full  access  toll  TADIXS  all  the 
time.  Someone  has  to  be  in  charge  of  bearer 
service  allocation.  This  means  that  the  doc¬ 
trine  for  TADIXS  information  flow  to,  from 
and  among  subordinate  TCCs  is  set  (dynami¬ 
cally,  based  on  the  tactical  situation)  by  the 
commander  of  the  senior  TCC,  who  must  have 
the  capability  (via  the  SEWC)  to  allocate 
TADIXS  capacity. 


Lag  Lia  Lv  Lia  Lai  L&i  L»s 


TCC  Subnet  1 


TCC  Subnet  2 


iiiiiiiiiiiiiitiiiiiiiiiiiiiiiniiiiiiiiiimiiiiimiimiiiiiiiiiimiiiiiiiiimiiiiiiiiiitiiiiiiiiiii 

TCC  Subnet  3 


Figure  7B-liZ.  What  is  a  TCC? 
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access  to  the  flagship 
system. 


external  communication 


The  TCC  encompasses  the  whole 
complex  of  afloat  and  command  activities. 
Whereas  the  existing  TFCC  is  merely  one  space 
within  a  flag-configured  ship,  the  TCC  will 
provide  an  integrated  construct  that  includes  not 
only  the  TFCC  itself,  but  also  the  other  spaces 
in  which  force  management  functions  are  ~ 
performed  such  as  CVIC,  SSES,  SUPPLOT, 
Combat  Direction  Center  (CDC),  and  radio. 


DESCRIPTION  OF  THE  OPERATIONAL 
MODEL 

TCCs  support  numbered  fleet  command¬ 
ers,  battle  force/battle  group  commanders,  am¬ 
phibious  task  force  commanders,  and  CWCs  to 
enable  them  to  exercise  their  responsibilities 
whether  as  naval  force  commanders,  joint  task 
organization  commanders,  or  allied  force  com¬ 
manders.  TCCs  help  the  tactical  commander  to: 


•  Respond  to  Fleet  Commander  in  Chief 
(FLTCINQ,  naval  component  commander,  JTF 
commander,  and  allied  force  commanders  direc¬ 
tives  and  policies; 

•  Coordinate  battle  group,  battle  force,  and/or 
amphibious  force  operations  in  crisis,  wartime, 
and  peacetime  environments; 

•  Prepare,  evaluate,  and  promulgate  mission  and 
mission  warfare  plans,  orders,  and  tactical  deci¬ 
sions; 


•  Allocate/reallocate  assigned  resources  includ¬ 
ing  dynamic  reconfiguration  of  communications 
assets  support; 

•  Assess  and  predict  tactical  situations  and  own 
force  readiness; 

•  Plan  transits,  search  and  rescue  operations; 
manage  catastrophic  civilian  relief  efforts;  per¬ 
form  air/water  space  management;  plan  frequency 
usage  and  manage  communication  and  informa¬ 
tion  management  systems;  drug  surveillance 
and  interdiction  support  operations;  and  conduct 
operational  planning  as  well  as  overall  informa¬ 
tion  management; 

•  Provide  all  elements  (Red,  White,  Blue,  Green)2 
of  the  near-real-time  tactical  picture  and  ensure 
a  consistent  tactical  picture  within  the  force  to 
enable  indications  and  warning;  intelligence  sup¬ 
port;  cryptologic,  imagery,  and  other  surveil¬ 
lance  support;  own  force  status  and  disposition 
monitoring;  logistics  support  to  own  force;  as 
well  as  consolidation  of  environmental/geophysi¬ 
cal  data; 

•  Coordinate  own  force  operations  with  those  of 
other  forces  and  ashore  commands; 

•  Provide  correlated,  evaluated  organic  and  non- 
organic,  multisource  tracks  and  amplifying  in¬ 
formation  to  own  forces  and  to  the  CCC  ashore; 

•  Prepare  targeting  information  and/or  targeting 
support  information; 

•  Plan  for  and  manage  assigned  collection  re¬ 
sources  and  coordinate  the  application  of  non- 
organic  collection  resources; 

•  Evaluate  warfare  and  warfare  support  system 
performance  and  contribution  to  mission  plan 
success; 


2  Blue-Friendly,  Red-Hostile,  White-Neutral,  Green-Environ¬ 
mental 
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•  Reconstitute  forces  after  action; 

•  Restore  communication  links  and  networks  after 
natural  or  man-made  degradation; 

•  Reconstruct  and  analyze  completed  exercises/ 
actions;  and 

•  Plan  for,  monitor,  assess,  observe  and  report  on 
their  delegated  warfare  tasks  in  response  to  the 
CWC’s  directives,  policies,  and  resource  alloca¬ 
tions.  Mission  warfare  commanders: 

-  Coordinate  with  each  other  when  the  force  is 
engaged  in  multi-warfare  operations;  coordi¬ 
nate  with  afloat  and  shore-based  counterparts 
when  operating  in  multi-force  operations; 

-  Prepare,  evaluate,  and  select  mission  warfare 
and  warfare  support  plans;  promulgate  the 
plans; 

-  Allocate/reallocate  assigned  resources; 

-  Direct  and  coordinate  assigned  forces  mis¬ 
sion  warfare  operations; 

-  Assess  situations;  evaluate  outcomes  as  op¬ 
posed  to  expectations; 

-  Develop  and  implement  preplanned  actions/ 
force  doctrines;  and 

-  Develop  and  implement  ad  hoc  actions. 


Critical  TCC  Functions 

An  initial  issue  to  be  resolved  is  the  scope 
of  the  TCC  capabilities.  Its  currently  existing 
counterpart,  the  Naval  Tactical  Communication 
System  Afloat  (NTCS-A),  supports  the  Officer 
in  Tactical  Command  (OTC)/CWC  and,  with 


the  addition  of  the  Electronic  Combat  (EC) 
Module,  the  Space  and  Electronic  Warfare  Com¬ 
mander  (SEWC.)  It  also  supports  the  host  ship 
command  structure.  Minimal  support  is  avail¬ 
able  for  specific  warfare  mission  areas  (e.g., 
development  and  evaluation  of  alternate  courses 
of  action  and  selection  of  an  optimum  course, 
development  of  a  doctrine  for  preplanned  ac¬ 
tions,  or  optimizing  allocation  and  reallocation 
of  mission  warfare  resources  for  combat  or  com¬ 
bat  support). 

The  OTC/CWC  decides  in  which  ships 
warfare  commanders/coordinators  will  embark. 
The  predominant  selection  seems  to  place  all  but 
the  Anti-Air  Warfare  Commander  (AAWC)  in 
the  CV/CVN.  Continuation  of  this  practice 
would  indicate  that  a  TCC  in  the  CV/CVN  must 
have  a  scope  of  capabilities  to  serve  not  only  the 
OTC/CWC,  but  also  the  Anti-Submarine  War¬ 
fare  Commander  (ASWC),  Anti-Surface  War¬ 
fare  Commander  (ASUWC),  Strike  Warfare 
Commander  (STWC),  SEWC,  and  Air  Resources 
Element  Coordinator  (AREC.)  The  AAWC  and 
the  Light  Air  Multi-Purpose  System  (LAMPS) 
Element  Coordinator  (LEC)  may  also  require 
support  from  the  CV/CVN  in  some  cases.  The 
CG/CGN,  the  preferred  AAWC  flagship,  would 
have  a  TCC  capable  of  supporting  specifically 
the  AAWC,  and  possibly  the  ASUWC,  and  the 
ASWC.  When  post-action  force  reconstitution 
is  considered,  however,  it  would  seem  prudent 
to  develop  a  single  TCC  that  can  support  the 
OTC/CWC  and  all  warfare  commanders/coor¬ 
dinators.  This  TCC  would  be  installed  in  all 
flag-configured  ships. 
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TCCs  installed  in  potential  Commander, 
Amphibious  Task  Force  (CATF)  flagships  (i.e., 
LCC,  LHD,  or  possibly  LHA  classes)  would  be 
augmented  by  amphibious  warfare  or  mine- 
warfare-unique  support  capabilities. 

The  capabilities  of  TCCs  installed  in 
numbered  fleet  commanders  flagships  (i.e.,  LCC, 
AGF,  or  a  CG/CGN)  would  be  augmented  to 
reflect  a  theater  scope  of  responsibilities;  multi-  - 
force,  joint,  and  allied  command  coordination; 
tactical  mobile  logistics  responsibilities;  and 
responsibilities  as  alternate  FLTCINCs. 

TCC  SUBSYSTEMS 

These  critical  TCC  functions  are  derived 
from  examination  of  only  the  OTC/CWC  and 
warfare  commander  user  functions,  current  sys¬ 
tems  capabilities,  and  systems  interfaces.  They 
are  identified  in  four  subsystem  categories:  in¬ 
formation  distribution,  information  processing, 
briefing  and  display,  and  facilities. 

The  information  distribution  subsystem 
connects  the  TCC  information  processing  sub¬ 
system  components  located  in  various  flagship 
spaces  with  each  other  and  with  the  briefing  and 
display  subsystem  located  in  the  command  cen¬ 
ter.  A  gateway  connects  this  TCC  local  area 
network  with  the  flagship  CS  S  for  interface  with 
other  force  platforms,  with  shore-based  com¬ 
mand  and  command  support  centers,  and,  in 
some  instances,  with  non-organic  sensors.  The 
subsystem  provides  all  requisite  communica¬ 
tion  system  interoperability,  compatibility,  adapt¬ 


ability,  reconfigurability,  and  security.  It  func¬ 
tions  in  secure  voice,  imagery,  data,  and  video 
modes.  The  information  distribution  subsystem 
terminus  of  the  information  processing  sub¬ 
system  is  the  communication  server. 

The  information  processing  subsystem 
provides  a  single  integrated  capability  for  users 
to  access  all  processing  resources  based  on  their 
requirements  and  authorized  data/application 
program  access.  Each  user  can  access  all  appli¬ 
cations  through  a  “single  window”  (or  succes¬ 
sor)  environment  that  provides  a  consistent  in¬ 
terface  to  all  applications. 

An  open  system  architecture  maintains 
the  flexibility  needed  to  accommodate  changing 
requirements  and  to  ensure  continuing 
interoperability  with  other  directly  (hardwire/ 
LAN)  or  indirectly  (radio  frequency  communi¬ 
cations)  connected  systems.  The  following  ca¬ 
pabilities  are  needed  in  the  TCC  information 
processing  subsystem: 

•  Data  interfaces  with  platform  support  systems 
(e.g.,  ACDS,  ASW  Module,  Prototype  Ocean 
Surveillance  Terminal): 

•  Data  interfaces  with  the  platform  CSS; 

•  Data  protocol  compatibility  among  subsystems; 

•  Automated  message  handling; 

•  Multilevel  security; 

•  LAN  with  access  to  platform  LANs  to  permit 
TCC  subscribers  to  share  authorized  intra-  and 
inter-platform  command  and  support  center  data, 
applications,  and  various  terminal  devices; 
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•  Standardized  user  interfaces  across  all  applica¬ 
tions  and  decision  aids; 

•  Office  automation; 

•  Datamanagementandstorageinarelationaldata 
base  environment; 

•  Integration  of  imagery  processing,  storage,  and 
distribution  into  development  of  organic  and 
non-organic  tactical  pictures  and  situation  as¬ 
sessments; 

•  High  resolution  (targeting  quality)  geographic 
and  topographic  maps  with  capabilities  to  over¬ 
lay  standardized  user-friendly  icons;  pan,  zoom, 
convert,  re-register,  and  to  annotate  with  narra¬ 
tive  or  graphic  data  to  support  mission  planning; 

•  User-oriented  tactical  decision  aids  including, 
planning,  assessment,  and  optimization  models; 

•  Briefing  preparation;  and 

•  Report  generation. 


The  briefing  and  display  subsystem  is 
comprised  of  video  switches,  controllers,  large 
screen  displays,  monitors,  and  teleconferencing 
and  audiovisual  support  equipment.  It 
intergraphic  display,  displays  created  by  a  TCC 
subscriber,  and  multi-media  displays  showing 
windows  and  overlays  of  user  desired  combina¬ 
tions  of  information  at  various  levels  of  granu¬ 
larity  and  command  levels. 

The  facility  subsystem  provides  the  space, 
power,  environmental  controls,  and  human  sup¬ 
port  responsive  to  the  needs  of  TCC  including 
decision  makers,  watchstanders,  analysts, 
maintenance,  and  administrative  personnel.  The 
limited  space,  weight,  power,  and  environmen¬ 
tal  support  capabilities  of  all  flag-configured 
platforms  place  a  severe  constraint  on  any  TCC 
design  criteria. 


RELATED  PROGRAMS 

There  is  one  major  program  element  that  is  making  significant  progress  toward  attaining 
Copernicus  TCC  capability:  Navy  Tactical  Command  System  Afloat  (NTCS-A).  This  program  has 
several  elements,  some  of  which  are  described  below: 

•  The  Joint  Operational  Tactical  System  (JOTS):  JOTS  work  stations,  the  primary  TFCC  system  component,  host 

common  tactical  data  processing  and  display  software  running  in  standard  hardware  for  the  OTC/CWC,  CATF  and 
CLF  and  selected  subordinate  warfare  commanders.  At  present,  JOTS  n  software  is  the  core  of  NTCS-A,  used  in 
conjunction  with  Navy  Desktop  Tactical  Computer  2  (DTC-2)  hardware  onboard  both  TCC  and  some  non-TCC 
units.  System  functionality  includes  track  management,  track  analysis,  environmental  prediction,  and  a  variety  of 
tactical  overlays  as  well  as  Tactical  Decision  Aids  (TDAs)/displays.  JOTS  is  capable  of  receiving  Link  11,  Link 
14,  TADIXS  A,  OTCIXS,  High  Interest  Track  (HIT)  Broadcasts,  Operational  Intelligence,  and  U.S .  Message  Text 
Format  (USMTF)  messages.  Link  16  data  will  be  processed  when  joint  Tactical  Information  Distribution  System 
(JT1DS)  is  introduced  into  the  fleet.  In  the  interim  (partially  integrated)  NTCS-A,  JOTS  interfaces  with  POST, 
TFCC  Information  Management  System  (TIMS),  Naval  Intelligence  Processing  System  (NIPS),  and  non-NTCS 
command  and  control  systems.  The  tactical  data  base  manager  (TDBM)  provides  a  consistent  tactical  picture  for 
all  supporting  warfare  commanders.  The  Fleet  Command  Centers  (FCCs)  interface  with  flag  configured  ships  and 
other  shore  nodes  via  a  JOTS  variant,  JVIDS  (Joint  Visually  Integrated  Display  System).  Data  is  exchanged  ship- 
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shore  via  the  Fleet  Broadcast,  the  SI  broadcast  and  Ocean  Surveillance  Product  (OSP),  and  among  shipboard  nodes 
via  OTCIXS  and  the  HIT  Broadcast  in  Over-  The-Horizon  (OTH)  Gold  and/or  tactical  report  (TACREP)  formats. 

•  Electronic  Warfare  Coordination  Module  (EWCM):  The  EWCM  was  designed  to  provide  planning,  decision 
aids,  and  automated  data  processing  support  for  the  CW C/OTC  and  the  Electronic  W arfare  Coordinator  (EW Q.  The 
EWCM  requirements  package  has  now  been  folded  into  NTCS-A  as  the  Electronic  Combat  (EC)  module  with 
software  supporting  EW  functions  performed  in  sea  control  and  power  projection  operations.  The  EW  Module  is 
being  implemented  in  both  the  SCI  and  GENSERNTCS  architectures  andis  the  core  supportpackage  for  the  SEWC. 
It  supports  tactical  planning,  direction  and  redirection  not  only  of  EC  resources  for  coordination  of  soft  kill, 
counter-threat  command  and  control,  communications,  computers  and  intelligence  counter  measures  (C4ICM) 
operations  to  degrade  the  enemy’s  C4I,  but  also  to  provide  C4I,  countermeasures  and  targeting  support  for  other 
warfare  commanders. 

•  The  Afloat  Correlation  System  (ACS):  ACS  was  to  be  a  ship-based,  on-line,  interactive,  near-real-time  support 
system  for  automated  correlation,  fusion  and  other  analytical  manipulation  of  multi-source  threat  information.  The 
ACS  was  to  be  installed  in  TFCC-equipped  ships.  ACS  requirements  have  been  folded  into  NTCS-A  as  software 
supporting  the  sea  control  and  power  projection  mission  planning,  execution,  and  threat  monitoring  functions.  SCI 
and  GENSER  ACS  functionality  supports  the  TFCC  and  interfaces  with  the  FCCs  (through  their  collocated  Fleet 
Ocean  Surveillance  Information  Centers  [FOSICs]).  ACS  functionality  is  used  to  correlate  the  ACDS  organic 
picture  with  off-board  sensor  derived,  non-organic  tactical  data  to  provide  the  OTC/CWC  with  a  single,  compre¬ 
hensive  and  consistent  tactical  picture.  Primary  offboard  inputs  are  the  shore-  generated  Ocean  Surveillance  Product 
(OSP)  via  TADIXS  A,  organic  data  maintained  by  the  ACDS,  and  non-organic  data  received  from  various 
communications  links  such  as  TADIXS  B,  TACINTEL  and  the  SI  broadcast.  Providing  limited  interim  correlator 
capabilities  are  POST  for  sea  and  the  Advanced  Tracking  Prototype  (ATP)  for  land.  In  FY92,  POST  and  ATP  will 
be  replaced  by  NTCS  software  that  will  field  an  improved  correlation  algorithm  for  land  as  well  as  sea  tracking  on 
DTC-2  workstations. 

•  The  Naval  Intelligence  Processing  System  (NIPS):  NIPS  supports  analysis  packaging  and  distribution  of 
intelligence  data  for  the  OTC/CWC,  CATF/CLF  and  subordinate  warfare  commanders/coordinators.  It  directly 
supports  strike  and  amphibious  warfare  by  providing  a  resource  for  mission  planning  and  organization;  intelligence 
assessment  and  evaluation;  photographic  and  electronic  imagery  transmission,  receipt,  interpretation,  and  exploi¬ 
tation;  reconnaissance  planning  and  analysis;  and  aircrew  briefing  and  debriefing.  NIPS  will  have  separate 
GENSER  and  SCI  processors;  a  GENSER-to-SCI  data  base  update  scheme  will  generate  an  all-source  tactical 
picture  at  the  SCI  level  to  support  OTC/CWC  and  especially  SEWC  SCI  resources  management  as  well  as  tactical 
intelligence  and  warning  (I&W)  and  GENSER  data  base  quality  assurance  (Q.A.).  Evolving  to  become  the 
NTCS-A  central  data  base  server  (CDBS),  NIPS  contains  technical  data  on  friendly,  neutral,  and  threat  systems  as 
well  as  characteristics  and  performance  (C&P)  data,  orders  of  battle,  and  other  capabilities.  Based  on  the  Naval 
Warfare  Tactical  Data  Base  (NWTDB),  this  data  base  provides  easily  accessible  information  in  support  of  other 
NTCS-A  components  and  Combat  Systems  such  as  ACDS,  Tactical  Air  Mission  Planning  System  (TAMPS)  and 
Tactical  EA-6  Mission  Planning  System  (TEAMS).  The  NIPS  data  base,  prepared  by  the  JIC/FIC  prior  to 
deployment,  is  tailored  to  projected  force  operational  requirements,  but  will  be  updatable  through  a  combination  of 
electrical  data  transmission,  tapes  and  manual  entry.  Near-term  upgrades  to  NIPS  will  include  porting  the  software 
to  DTC-2  data  base  expansion. 
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CHAPTER  8 

BUILDING  BLOCKS  OF  THE  ARCHITECTURE 


REFERENCES: 
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Information  System;  15  May  1991  (Draft) 

(d)  MIL-STD-1813,  Network  Management  forDOD  Communications;  10  June 
1991  (Draft) 

(e)  Communication  Support  System  (CSS)  Overview  (Draft),  October  1990 


SUMMARY 

Precedingchaptershavepresentedanoperationallyorientedviewofthearchitecture.  Thischapterpresentsaview 
of  the  architecture  in  terms  of  how  it  should  be  designed  and  implemented.  Each  pillar  of  the  architecture  (presented  in  fig. 
8-1)  has  some  unique  characteristics,  but  strong  common  elements  bind  the  pillars  together  to  form  the  architecture. 

the  first  common  element  is  the  virtual  nature  of  all  four  pillars.  Global  Information  Exchange  System 
(GLOBIXS)  and  Tactical  Data  Information  Exchange  System  (TADIXS)  are  virtual  communication  services  that  use 
physical  bearer  services  for  transmission.  CINC  Command  Complex  (CCQ  and  Tactical  Command  Center  (TCC) 
employ  virtual  command  control  services,  permitting  personnel  in  physical  command  center  spaces  to  interact  as  if  all  the 
physical  spaces  were  one.  The  second  eiementis  the  use  of  functions  to  define  die  services.  This  structured  approach  to 
Service  definition  permits  common-user  needs  to  be  identified.  The  third  commonality  is  the  application  of  building  blocks 
to  these  functions.  Building  blocks  identify  in  engineering  terms  how  the  architecture  is  to  be  achieved.  The  Common 
Operating  Environment  (COE)  is  the  final  element  among  the  pillars,  providing ;  the  technical  standards  that  cement 
building  blocks  into  the  architecture. 

This  chapter  also  presents  (in  annexes  A  B,  and  C)  the  network  management  services,  communication  bearer 


Figure  8-1.  The  Pillars  of  tbe  Copernicus  Architecture 
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At itshighest level,  the engineering model  is  based  on  the mapping of  virtual  services  (e.g.,  communication,  data 
base,  analyst  support  services)  tophysical,  iraplementable  items;  Figure  8-2  presents  this  concept  in  a  diagram.  GLOBIXS 
communkation  services  use  physical  communication  servers  to  access  physical  transmission  systems  and  packet-  or 
circuit-switched  network  services.  People  using  workstations  in  CCC  use  virtual  communication  services  and  employ 
distributed  databaseand  operating  system  facilities  to  use  software  veneers  running  on  computers  throughout  the  CCC  and 
on  computers  at  GLOBIXS  nodes.  TADIXS  communication  services  use  tactical  transmission  systems  and  networking 
capability  provided  by  the  CSS  hardware  and  software.  TCC uses  the  same  distributed  computing  base^as  does  CCC,  to 
provide  tactical  commanders'  staffs  free  access  to  information. 
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VIDEO  DATA  VOICE 


GLOBIXS 

Nodes 
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Figure  8-2.  Conceptual/Physical  Architectural  Mapping 

JFigure  8-3  presents  the- functions that  engineering  design  must  address;  The  figure  re-en^ 
commonality  among  functionally  simi lar  pillars:  GIX)BDCS  andTADIXS;  CCC  -jand;^ 

Copernicus  implementations  use  the  building  blocks  represented  in  figure  8-4^ 

Building  blocks  in  the  “GLOBDCS**  column  of  the  figure  are,  for  the  most  part,  obtainable  today.  Defense 
Communication  System  (DCS)  communication  services  are  increasing  in  importance.  Base  Information  Transfer 
System  (BITS)  is  the  wideband  local  and  metropolitan  area  network  (LAN/MAN)  to  connect  nodes  in  the  CCC.  Secure 
voice  communication  is  available  by  using  Secure  Telephone  Unit  III .(STUPID)'  and  (at  unified  commander  in  chief 
[USCINC3  command  centers)  Red  S  witch  systems.  Federal  Telecommunication  System  2000  (FTS2000)  is  an  existing 
common-user  voice  and  data*  circuit-andpacket-s  witched  network  administeredby  the  Generic  Seivices  Administratibn 
(GSA).  Early  transliterator  implementationsarein service  now.  Prototype  sanitizers  are  also  in  use.  Furtherdevelopmenf 
of  transfiterator  tecfmologyh^  within  the  grasp  of  industry .  Research  and 

:  deveIopment  on  muItilevel  security  (MLS)  systems  can provide  additional  benefits;  but MLS,  while  highly  desirable,  is 
hot  a  prerequisite  for  GLGBIXSim^ 

CCC  building  blocks  are  also  well  within reach.  Introduction  of  the  Navy  Desktop  Tactical Computer  2 ijYtCy 
2)  has  shown  that  it  is  feasible  to  target  implementations  on  a  family  of  computing  engines,  with  a  view  toward  follow- 
on  expansion  to other  evoluntionary  engines  in  the  future.  LANs  provide  service  for  ill  fleet  commander  m  chief 
(FUICINC)  headquarters  and  in  many  other  shore  stations  as  well.  CSS  has  successfully  completed  ^ 
demonstr^  is  preparing  for  implementation  with  initial  operational  capabifity  (IGK^  in  EY  93;  Commt^ 

servers  are  commercially  available,  but  it  is  important  to  select  servers  that  can  be  managed  by  Open  Systems 
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Figure  83*  Identification  of  Copernicus  Pillar  Functions 


Figure  8-4.  Copernicus  Building  Blocks 
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Interconnection  (OSI)  network  management  protocols.  Data  base  service  has  made  significant  progress  with  implemen¬ 
tation  of  relational  data  bases,  and  further  improvements  are  anticipated  through  the  use  of  object-oriented  data  bases. 

TADIXS  building  blocks  depend  on  similar  network  management,  security,  standards,  and  protocols  as 
GLOBIXS.  TADIXS  also  depends  on  government-developed  bearer  services  (discussed  in  detail  in  annex  B). 

TCC  building  blocks  are  similar  to  CCC  blocks,  except  that  an  afloat  LAN  is  used  rather  than  the  BITS  LAN. 
Similarly,  CSS  is  the  only  source  of  communication  services. 

Today,  in  some  cases,  morethanone  existing  program  is  developingacapability  that  can  serve  asa  building  block 
of  the  architecture.  In  these  cases,  the  Navy  must  carefully  consider  the  requirement  for  two  very  similar  building  blocks 
and  choose  one  among  these  as  theCopemican  “standard”.  By  that  means  itshould  be  possible  to  selecta  “best  of  breed” 
that  would  receive  strong  programmatic  and  management  support  for  application  to  the  architecture. 

The  final  feature  of  the  engineeringmodel  ispresentedinrfigure8*5fwhich  shows  thestandards  that  ereatea  COE. 
The  elementsof  this  COEhave  been  jointly  agreedon  by  the  Army  staff  and  Air  Force  staff  proponents  for  C4I,  the  Marine 
Corps  Director  of  C4S,  and  the  Navy  Director  of  Space  and  Electronic  Warfare  (SEW)  (OP-094).  The  COE  is  being 
implemented  by  the  Navy  Tactical  Command  System  Afloat  (NTCS-A)  and  by  CSS.  The  COE  is  a  military 
implementation  of  reference  (a). 

Individual  engineering  models  of  the  four  pillars  are  presented  in  the  following  text  Due  to  the  strong 
commonality  among  the  fourpillars  (andparticularly  in  the  GLOBIXS/TADIXS,  CCC/TCC  sets),  some  detail  presented 
in  the  GLOBIXS  and  CCC  sections  will  not  be  repeated  in  the  TADIXS  and  TCC  sections. 
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Figure  8-5.  A  Notional  Copernicus  COE 
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DISCUSSION 

At  its  highest  level,  the  engineering 
model  is  based  on  the  mapping  of  virtual  ser¬ 
vices  (e.g.,  communications,  data  base,  analyst 
support  services)  to  physical,  implementable 
items.  Figure  8-2  presents  this  concept  in  a 
diagram.  GLOBIXS  communications  services 
use  physical  communications  servers  to  access 
physical  transmission  systems  andpaeket-t>r 
circuit-switched  network  services.  People  using 
workstations  in  the  CCC  use  virtual  communi¬ 
cations  services  and  employ  distributed  data 
base  and  operating  system  facilities  to  use  soft¬ 
ware  veneers  running  on  computers  throughout 
the  CCC  and  on  computers  at  GLOBIXS  nodes. 
TADIXS  communications  services  use  tactical 
transmission  systems  and  networking  capability 
provided  by  the  CSS  hardware  and  software. 
TCC  uses  the  same  distributed  computing  base 
as  does  CCC  to  provide  tactical  commanders' 
staffs  free  access  to  information. 

BUILDING  BLOCKS 

Figure  8-3  presents  the  functions  that 
engineering  design  must  address.  The  figure  re¬ 
emphasizes  the  strong  commonality  among  func¬ 
tionally  similar  pillars:  GLOBIXS  and  TADIXS, 
CCC  and  TCC.  To  provide  these  functions, 
Copernicus  implementations  use  the  building 
blocks  represented  in  figure  8-4. 


GLOBIXS  Building  Blocks 

Building  blocks  in  the  “GLOBIXS”  col¬ 
umn  of  the  figure  are,  for  the  most  part,  obtain¬ 
able  today.  DCS  communications  services  are 
used  by  existing  Naval  telecommunications  and 
are  increasing  in  importance.  BITS  is  the 
wideband  LAN  and  MAN  to  connect  nodes  in 
the  CCC.  Secure  voice  communication  is  avail¬ 
able-  by  using  STU  m  and  at  (USCINC  com¬ 
mand  centers)  Red  Switch  systems.  FTS2000  is 
an  existing  common-user  voice  and  data,  cir¬ 
cuit-  and  packet-switched  network  administered 
by  the  GSA.  Early  transliterator  implementa¬ 
tions  are  in  service  now.  Prototype  sanitizers  are 
also  in  use.  Further  development  of  transliterator 
and  sanitizer  technology  has  been  assessed  to  be 
well  within  the  grasp  of  industry  (see  chap.  4). 
Research  and  development  on  MLS  systems  can 
provide  additional  benefits,  but  are  not  prerequi¬ 
site  for  GLOBIXS  implementation. 

CCC  Building  Blocks 

CCC  building  blocks  are  also  well  within 
reach.  Introduction  of  the  DTC-2  has  shown  that 
it  is  feasible  to  target  implementations  on  a 
family  of  computing  engines,  with  a  view  to¬ 
ward  follow-on  expansion  to  other  evolutionary 
engines  in  the  future.  LANs  provide  service  for 
all  FLTCINC  headquarters  and  in  many  other 
shore  stations  as  well.  CSS  has  successfully 
completed  technology  demonstration  and  is  pre¬ 
paring  for  implementation  with  IOC  in  FY  93. 
Communications  servers  are  commercially  avail¬ 
able,  but  it  is  important  to  select  servers  that  can 
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be  managed  by  OSI  network  managementproto- 
cols  (see  chap.  3).  Data  base  management  has 
made  significant  progress  with  implementation 
of  relational  data  bases,  and  further  improve¬ 
ments  are  anticipated  through  use  of  object- 
oriented  data  bases. 


TADIXS  Building  Blocks 

TADIXS  building  blocks  depend  on  simi¬ 
lar  network  management,  security,  standards, 
and  protocols  as  GLOBDCS.  TADIXS  also  de¬ 
pends  on  government-developed  bearer  services 
(discussed  in  detail  in  annex  B). 

TCC  Building  Blocks 

TCC  building  blocks  are  similar  to  CCC 
blocks,  except  that  an  afloat  LAN  is  used  rather 
than  the  BITS  LAN.  Similarly,  CSS  is  the  only 
source  of  communication  services. 

Today,  in  some  cases,  more  than  one 
existing  program  is  developing  a  capability  that 
can  serve  as  a  building  block  of  the  architecture. 
In  these  cases.  Navy  must  carefully  consider  the 
requirement  for  two  very  similar  building  blocks 
and  choose  among  these  as  the  Copernicus  “stan¬ 
dard.”  By  that  means  it  should  be  possible  to 
select  a  “best  of  breed”  that  would  receive  strong 
programmatic  and  management  support  for  ap¬ 
plication  to  the  architecture. 

The  final  feature  of  the  engineering  model 
is  presented  in  figure  8-5,  which  show  the  stan¬ 


dards  that  create  a  COE.  The  elements  of  this 
COE  have  been  jointly  agreed  on  by  the  Army 
and  Air  Force  staff  proponents  for  C*I,  the  Ma¬ 
rine  Corps  Director  of  OS,  and  the  Navy  Direc¬ 
tor  of  SEW  (OP-094).  The  COE  is  being  imple¬ 
mented  in  NTCS-A  and  in  CSS.  The  COE  is  a 
military  implementation  Of  reference  (a). 

Individual  engineering  models  of  the 
four  pillars  are  presented  in  the  following  text. 
Due  to  the  strong  commonality  among  the  four 
pillars  (and  particularly  in  the  GLOBDCS/ 
TADIXS,  CCC/TCC  sets),  some  detail  presented 
in  the  GLOBDCS  and  CCC  sections  will  not  be 
repeated  in  the  TADIXS  and  TCC  sections. 

GLOBIXS  ENGINEERING  MODEL 

GLOBDCS  virtual  services  are  indicated 
in  figure  8-6  with  relation  to  other  pillars.  They 
are  described  in  Chapter  4  in  operational  terms. 

GLOBIXS  Technology  Basis 

The  two  primary  technological  develop¬ 
ments  that  make  GLOBDCS  possible  are: 

•  Large  amounts  of  terrestrial  digital  band¬ 
width  at  low  per  unit  cost  often  because  of 
optical  fiber  facilities;  and 

•  Distributed  stored  program  control  of  tele¬ 
communication  transmission  and  switching 
facilities. 

Distributed  stored  program  control  en¬ 
ables  network  managers  to  assign  transmission 
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Figure  8-6.  Relationship  of  GLOBIXS  to  Other  Copernican  Pillars 


channels  dynamically  on  an  end-to-end  basis, 
keep  track  of  their  configuration,  and  do  fault 
isolation  and  restoration.  The  bandwidth  mix  of 
such  channels  is  also  very  adaptable  in  multiples 
and  submultiples  of  64  kbps  ranging  up  to  speeds 
of  hundreds  of  Mbps.  Standard  network  man¬ 
agement  structures,  interfaces,  and  services  as 
well  as  access  controls  allow  user-communities 
to  administer  and  adapt  those  channels  assigned 
to  them. 

User  communities  can  administer  and 
update  their  own  network  directories  without 
losing  compatibility  with  global  directories  and 
directories  of  other  user  communities. 

Transmission  cross-sections  in  the  hun¬ 
dreds  and  thousands  of  Mbps  that  can  be  quickly 
subdivided  and  reallocated  to  allow  such  net¬ 
works  to  be  created  economically.  Soon  the 
availability  of  non-blocking  switches  based  on 


accepted  worldwide  standards  that  can  handle 
any  service  from  75  bps  TTY  to  high  definition 
television  (i.e.,  broadband  Integrated  Services 
Digital  Network  [ISDN])  will  allow  the  net¬ 
work  manager  to  make  it  appear  to  user  commu¬ 
nities  as  if  they  have  a  virtual  network  they 
control. 

Because  services  and  interfaces  would 
be  common  to  all  networks,  virtual  networks 
could  interoperate  as  well  as  having  simulta¬ 
neous  user  access  to  shared  networks. 

Available  networks  that  can  offer  this 
capability  today  are  Defense  Commercial  Tele¬ 
communications  Network  (DCTN)  or  FTS2000. 
Other  networks  soon  will  be  available  including 
Navy  Network  (NAVNET),  wideband  Defense 
Data  Network  (DDN),  and  Defense  Integrated 
Secure  Network  (DISNET).  A  future  network 
would  be  the  Defense  Integrated  Services  Net- 
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work  (DISN).  It  is  expected,  however,  that  the 
DCS  would  be  the  primary  vehicle  since  its 
network  management,  administrative,  security, 
and  services  structure  would  be  most  compatible 
with  the  GLOBIXS  concept 

The  following  presents  a  summary  of 
three  elements  common  to  GLOBIXS  and 
TADIXS,  which  are  necessary  to  bind  effec¬ 
tively  these  elements  into  the  architecture;  1) 
management  services,  2)  bearer  services,  and  3) 
user  communication  services. 

GLOBIXS/TADIXS  Management  Services 

This  category  of  services  allows  plan¬ 
ners,  maintainers,  and  operators  of  communica¬ 
tion  services  to: 

•  Make  the  best  fit  of  available  capability  to 
the  operational  requirement; 

•  Intelligently  use  available  on-line  mecha¬ 
nisms  to  keep  systems  operating;  and 

•  Make  the  best  use  of  available  capability. 

The  categories  of  management  service 
are  standard  OSI  network  management  catego¬ 
ries.  Annex  A  presents  a  detailed  description  of 
these  services  as  they  apply  to  GLOBIXS  and 
TADIXS. 

In  addition  to  the  management  services 
described  in  Annex  A,  GLOBIXS  (and TADIXS) 
managers  will  require  software  veneers  of  appli¬ 
cation  programs  to  use  effectively  data  gathered 


through  configuration  management  and  account¬ 
ing  management.  This  capability  is  required 
both  for  operation  and  for  planning. 

GLOBIXS/TADIXS  Bearer  Services 

Transmission  systems  often  are  referred 
to  as  bearer  services.  They  are  the  physical  layer 
subsystems  that  provide  the  radio  or  wireline 
path  for  GLOBIXS  and  TADIXS  virtual  net¬ 
work  services.  Bearer  services  connect  one  unit 
with  another. 

GLOBIXS/TADIXS  User  Communications  Services 

Copernicus  communication  services  are 
functional  and  operational  information  exchange 
pathways.  They  are  not  individual  communica¬ 
tions  streams  or  separate  communications  nets. 
Instead,  they  will  share  access  to  the  various 
bearer  services  (detailed  in  annex  B).  There  are 
precursors  to  the  Copemican  TADIXS,  although 
there  are  no  virtual  networks  that  currently  serve 
the  operating  forces.  One  precursor  to  Copemi¬ 
can  TADIXS  is  the  Officer  in  Tactical  Com¬ 
mand  Information  Exchange  Subsystem,  Phase 
II  (OTCIXS  II).  Annex  C  presents  a  detailed 
discussion  of  these  and  other  user  communica¬ 
tion  services. 

CCC  ENGINEERING  MODEL 

Figure  8-7  presents  the  relationship  of 
CCC  to  the  other  pillars  of  the  architecture. 
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There  are  five  elements  of  the  model  to  be 
considered:  evolutionary  architecture,  evolving 
technologies,  standards,  application  programs, 
and  data  bases. 


Evolutionary  Architecture 


The  CCC  builds  on  the  evolutionary 
open  systems  architecture  model  of  the  Navy 
Command  and  Control  Systems  (NCCS)  and  the 
NTCS-A,  achieving  optimum  commonality  and 
interoperability  among  computer  systems  in¬ 
stalled  in  the  CCC  and  TCC  and  with  interfacing 
centers.  A  high  degree  of  commonality  is  found 
in  data  bases  and  application  programs  in  the 
Fleet  Command  Center  (FCC),  Operations  Sup¬ 
port  System  (OSS),  Shore  Anti-Submarine  War¬ 
fare  (ASW)  Command  Center  (SACC),  Subma¬ 
rine  Operations  Control  Center  (SOCC),  and 


ASW  Operations  Centers  (ASWOCs).  Unique¬ 
ness  is  readily  apparent  in  the  Joint  Intelligence 
Center  (JIC),  Fleet  Numerical  Oceanographic 
Center  (FNOC),  Naval  Western  Oceanographic 
Command  (NWOC)  and  the  Naval  Computer 
and  Telecommunications  Area  Master  Stations 
(NCTAMS).  Figure  8-8  compares  the  major 
engineering  constructs  of  current  Navy  shore- 
based  and  afloat  systems. 

Evolving  Technologies 

The  CCC  also  builds  on  the  evolving 
technologies  of  multimedia  networking  and  dis¬ 
tributed  systems  that  facilitate  graceful  growth 
and  modernization  at  less  cost  than  earlier  stand 
alone  systems.  Equally  important,  these  tech¬ 
nologies  provide  an  engineering  means  to  achieve 
desired  levels  of  computer  system  and  commu- 
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Figure  8-8.  Command  and  Control  Systems  Comparison 


nication  system  interoperability  within  and  be¬ 
tween  Navy  centers  and  between  Navy  centers 
and  national,  joint,  and  allied  centers.  The 
technologies  also  aid  in  implementing  load- 
sharing  and  load-balancing  between  systems 
within  command  centers  and  between  geographi¬ 
cally  dispersed  systems. 

Standards 

Modular  and  common  design  and  acqui¬ 
sition  approaches  will  reduce  development  and 
implementation  time,  system  operator  and  main¬ 
tenance  training  time,  and  numbers  of  required 


personnel.  These  factors  imply  identification 
and  design  of  incremental  improvements  to  ex¬ 
isting  CCC/TCC  systems  that  will  move  the 
CCC/TCC  to  the  desired  spectrum  of  common¬ 
ality  and  interoperability. 

Strong  configuration  management  en¬ 
sures  that  developments  conform  to  an  evolving 
and  guiding  architecture  and  incremental  re¬ 
quirements.  It  enhances  the  probability  of  easy 
integration  of  new  products  into  existing  con¬ 
figurations. 

Application  of  relevant  Federal  Govern¬ 
ment,  DOD,  and  industry  standards  helps  to 
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achieve  interoperability,  reduces  manpower/ 
training  costs,  and  minimizes  development  and 
logistics  support  costs.  These  standards  are  de¬ 
rived  from  sources  such  as  references  (a)  through 
(d)  and  related  development  and  acquisition 
documents,  commercial  off-the-shelf  (COTS), 
government  off-the-shelf  (GOTS),  Government 
Open  Systems  Interconnection  Profile  (GOSIP), 
SOE,  COE,  and  proven  nondevelopmental  item 
(NDI)  products.  Standard  use  of  selected  com*- 
puter-aided  software  engineering  tools  will  as¬ 
sist  in  reducing  software  development  time  and 
cost. 

A  CCC  development  effort  to  encourage 
the  reuse  of  existing  software  applicable  to  each 
increment  will  be  initiated.  Trade-off  analysis 
will  assess  cost  and  risk  of  porting  old  software 
to  a  new  configuration  instead  of  initiating  soft¬ 
ware  development.  OSS  and  NTCS-A  experi¬ 
ence  in  this  area  will  be  applied  to  CCC/TCC 
development. 

Application  Programs 

The  CCC/TCC  will  feature  a  distributed 
applications  processing  environment.  Applica¬ 
tions  will  include  computations  (e.g.,  data  fu¬ 
sion,  correlation,  closest  point  of  approach 
(CPA),  track  projections,  probabilities/statistics 
calculations);  specific  models;  data  source  cata¬ 
logs;  application  program  description/location 
catalogs;  and  tactical/strategic  decision/planning 
aids.  Networks  will  provide  the  media  for  ac¬ 
cessing  local  and  distant  needed/authorized  ap¬ 
plication  programs. 


Data  Bases 

The  CCC/TCC  data  base  will  be  orga¬ 
nized  from  the  best  features  of  the  OSS  and 
NTCS-A  data  bases.  The  construct  of  the  elec¬ 
tronic  support  measures  (ESM)  portion,  how¬ 
ever,  will  be  decided  after  completion  of  an 
examination  of  the  current  multiple  ESM  data 
bases. 

The  CCC/TCC  will  adapt  an  object-ori¬ 
ented  design  for  its  data  base  and  data  base 
management  schemes.  Rules  of  data  relation¬ 
ships  and  object  interactions  will  provide  the 
logic  for  intra-  and  inter-  organization  informa¬ 
tion  management  consistency.  In  addition,  the 
data  management  scheme  will  facilitate  ready 
retrieval  of  multimedia  information  related  to  a 
particular  subject  or  situation. 

TADIXS  ENGINEERING  MODEL 

Figure  8-9  indicates  the  TADIXS  rela¬ 
tionship  to  other  pillars  of  the  architecture.  It 
should  be  emphasized,  however,  that  TADIXS 
provide  virtual  networks  among  the  forces  afloat 
as  well  as  linking  the  CCC  and  TCC. 

CSS  is  the  single  most  important  ele¬ 
ment  of  the  TADIXS  engineering  model.  Chap¬ 
ter  6  provided  an  operationally-oriented  discus¬ 
sion  of  CSS  features;  reference  (e)  addresses 
technology  applications.  CSS  provides  the  abil¬ 
ity  for  the  tactical  commander,  through  the  Space 
and  Electronic  Warfare  Commander  (SEWC) 
staff,  to  control  TADIXS  in  a  manner  analogous 
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to  the  fashion  other  commanders  control  ASW, 
Anti-Surface  Warfare  (ASUW),  or  Anti-Air 
Warfare  (AAW)  forces. 

The  three  services  addressed  in  connec¬ 
tion  with  the  GLOB  DCS  Engineering  Model  (see 
annexes  A,  B,  and  C)  are  valid  for  TADDCS  as 
well.  Of  at  least  equal  importance,  however,  are 
bearer  service  improvements  that  will  continue 
recent  improvements  in  tactical  communica¬ 
tion.  Pre-eminent  among  these  is  the  fitting  of 
super  high  frequency  (SHF)  satellite  communi¬ 
cations  (SATCOM)  capability  on  combatant 
ships.  This  high  quality,  relatively  wide  band¬ 
width  (32  kbs  up  to  a  potential  capacity  of  1 .544 
Mbs)  bearer  service  with  some  anti-jam  capabil¬ 
ity  will  enhance  Cl  afloat  significantly. 

Other  key  elements  of  the  TADDCS 
engineering  model  include  bearer  service 
improvement  programs:  the  Satellite  Integrated 


Terminal  program  for  ultra-high  frequency 
(UHF)  SATCOM,  Navy  Extremely  High 
Frequency  (EHF)  SATCOM  Program  (NESP), 
potential  medium  data  rate  service  (MDR)  from 
EHF  SATCOM  space  craft,  and  commercial 
SATCOM  afloat. 

TCC  ENGINEERING  MODEL 

The  TCC  (see  fig.  8-10)  builds  on  the 
evolutionary  open  systems  architecture  model 
of  the  NCCS  ashore  and  the  NTCS-A  to  achieve 
optimum  commonality  and  interoperability 
among  computer  systems  installed  in  the  TCC 
and  CCC  command  and  command  support  cen¬ 
ters  and  with  interfacing  centers.  Figure  8-2 
shows  a  conceptual  model  of  a  modular,  distrib¬ 
uted  TCC.  Figure  8-8  compares  the  major  engi¬ 
neering  constructs  of  current  Navy  shore  and 
afloat-based  systems. 
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There  is  a  high  degree  of  commonality 
(both  needed  and  existing)  among  the  multiple 
data  bases  supporting  the  current  NTCS-A  and 
the  FCC.  The  most  significant  differences  are 
the  extent  of  dynamic  track  data  in  the  TCC  data 
base  and  low  time  perishability  of  track  and 
support  (environment,  readiness,  engagement 
situations)  data.  The  FCC  can  focus  on  the  same 
area  of  responsibility  that  the  Officer  in  Tactical 
Command  (OTC)  is  viewing,  but  the  data  may 
be  time  late  or  more  in  the  aggregate  than  is 
usable  to  the  OTC. 


Multimedia  networking  and  distributed 
systems  technologies  coupled  with  availability 
of  standard  operating  systems  facilitate  graceful 
growth  and  interoperability  and  provide  means 
for  local  and  distant  load-sharing  and  load-bal¬ 
ancing. 

The  standards,  application  programs,  and 
data  base  elements  of  the  TCC  engineering  model 
are  the  same  as  those  presented  in  the  discussion 
of  the  CCC  engineering  model. 


Consistency  in  data  and  data  protocols 
such  as,  resolution,  registration,  coordinates, 
protocols,  formats,  data  base  file  structures,  and 
data  definitions,  among  others,  is  an  objective 
that  will  be  pursued  incrementally  as  the  CCC/ 
TCCs  evolve. 


Specific  Configurations 

Numbered  Fleet  Flagships.  In  numbered  fleet 
commander  (NFC)  flagships,  TCC  systems  are 
not  required  generally  to  interface  with  combat 
systems  or  sensors  but  must  have  large  data  base 
and  processing  capacities  for  data  storage/ma¬ 
nipulation  relative  to  the  area  of  responsibility 
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(AOR).  Additionally,  such  TCCs  may  have 
specialized  strategic  planning,  tactical  decision 
aids  (TDA),  as  well  as  employment  scheduling 
and  logistics  planning  capabilities. 

LCC/LHD  in  Amphibious  Flagships.  TCCs 
serving  Commander,  Amphibious  Task  Force/ 
Commander,  Landing  Force  (CATF/CLF)  as 
well  as  other  embarked  ground  and  Special 
Forces  elements  must  have  sea  and  land-ori¬ 
ented  data  bases  and  tailored  TDAs.  Special 
plug-in/plug-out  tactical  data-processor  arrange¬ 
ments  support  data  bases  ashore  to  sustain  con¬ 
sistency  with  afloat  data  bases.  While  em¬ 
barked,  LAN  connectivity  may  extend  to  USMC 
systems  such  as  TERPES1  and  PLRS2.  Dedi¬ 
cated  links  extend  TCC  support  to  forces  ashore 
until  handover  of  responsibility  to  CLF. 

CV/CVN.  TCCs  serve  Battle  Force  (BF)  and 
Battle  Group  (BG)  Commanders  and  embarked 
subordinate  commanders  and  their  staffs  using 
dual  ring  (Sensitive  Compartmented  Informa¬ 
tion  (SCI)  and  general  service  [GENSER])  LANs 
to  provide  inter-  and  intra-system  connectivity. 
This  includes  combat  direction  systems  such  as 
Advanced  Combat  Direction  System,  Tactical 
Air  Mission  Planning  System,  Tactical  EA-6 
Mission  Planning  System,  CV-ASW  Module, 
and  organic  sensors  such  as  BGPHES3  and 
TARPS4,  and  associated  support  centers  (e.g., 


Ship's  Signal  Exportation  Space,  Carrier  Intelli¬ 
gence  Center,  Supplemental  Plot).  Carrier  TCCs 
will  be  capable  of  the  full  range  of  sea  control 
andpowerprojection  functionality  while  having 
an  air  operations  orientation  in  TDAs. 

Major  Combatants.  TCCs  in  cruiser  classes 
(and  destroyer,  frigate,  SSN,  etc.)  serve  warfare 
commanders  generally  in  AAW,  ASW,  and 
ASUW  roles.  Cruiser/destroyer  capabilities  will 
be  a  subset  or  downsized  version  of  carrier 
TCCs. 

Other  Applications.  Due  to  the  unique 
multimission  nature  of  SSN  operations  as  either 
part  of  a  BG  organization  or  conducting  inde¬ 
pendent  operations,  a  smaller,  tailored  TCC  will 
be  an  adjunct  to  the  submarine’s  mainframe 
combat  control  system.  This  TCC  will  provide 
the  necessary  connectivity  forintelligence,  threat 
data,  environmental  conditions,  water  space 
management,  targeting,  and  command  and  con¬ 
trol  with  either  the  BG  commander  or  SSOC. 

Similar  special  application  TCC's  could 
be  easily  established  afloat  or  ashore  as  part  of  a 
mobile  command  center  in  support  of  unconven¬ 
tional  warfare  or  other  unique  mission  areas. 
The  flexibility  of  the  Copernicus  architecture  is 
the  key  to  meeting  these  requirements. 


*  Tactical  Electronic  Reconnaissance  Processing  and  Evaluation 
System  (TERPES). 

2  Position  Location  Reporting  System  (PLRS). 

3  Battle  Group  Passive  Horizon  Extension  System  (BGPHES). 

4  Tactical  Airborne  Reconnaissance  Pod  System  (TARPS). 


ANNEX A 
NETWORK  MANAGEMENT 


The  following  descriptions  of  standard  network  management  services  are  tailored  to  Navy 
GLOBIXS  and  TADIXS  implementations.  As  stated  in  Chapter  4,  Navy  will  use  COTS  implementation 
for  communication  among  shore  establishment  nodes.  Navy  personnel  managing  communications, 
however,  should  not  be  required  to  leant  different  management  functions  for  shore  and  fleet  communi¬ 
cations.  Network  management  implementations,  therefore,  will  use  the  Copernicus  human  machine 
interface  (HMI)  as  the  standard  representation  of  communication  processes  and  mechanisms  that 
manage  them. 

The  Navy  does  not  require  unique  network  management  capability.  The  Navy  does  require  that 
COTS  implementations  provide  the  functions  listed  below  (or  be  capable  of  being  adapted  to  provide 
these  functions).  Above  all.  Navy  requires  that  the  management  interface  be  the  Copernicus  CSS  HMI. 

Network  management  encompasses  the  functions  of: 

•  Configuration  management; 

•  Performance  management; 

•  Fault  management; 

•  Security  management;  and 

•  Accounting  management 


CONFIGURATION  MANAGEMENT 

Configuration  management  serves  planners,  maintained,  and  operators  by  assuring  a  common 
reference  of: 

•  What  resources  are  available; 

•  Which  are  in  use;  and 

•  How  they  can  be  used  (both  technical  capability  and  doctrinal  constraints). 

The  following  briefly  outlines  requirements  for  GLOBIXS  and  TADIXS  planners,  maintained, 
and  operators  to  use  configuration  management. 


GLOBIXS  Use  of  Configuration  Management 

GLOBIXS  claimant  planning  is  a  relatively  long-term  activity.  Configurations  will  be  designed 
to  permit  user  communities  to  establish  virtual  networks  for  information  exchange,  and  these  configu¬ 
rations  will  not  change  frequently  (except  at  local  sites,  where  consumer  premise  equipment  (CPE) 
frequently  will  be  moved  among  offices).  The  claimant  for  each  GLOBIXS  will  use  configuration 
management  to  keep  track  of  bearer  services  that  support  the  GLOBIXS,  to  monitor  how  CCC  and  other 
users  are  employing  bearer  services  and  GLOBIXS,  and  to  plan  for  future  expansion  of  bearer  services. 
Site  administrators  will  provide  configuration  management  “upload”  of  local  site  configuration 
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information  to  the  claimant.  Nodal  personnel  (similar  to  DCS  technical  control  station  or  patch  and  test 
facility)  will  upload  node  and  inter-site  information  in  an  automated  process  similar  to  current  DCS 
circuit  card  maintenance  procedures.  Naval  Computer  and  Telecommunications  System  stations  will 
upload  regional  and  communication  area  information  (for  shore-to-shore  bearer  services  and  networks). 

At  a  Navy-wide  level,  claimants  will  provide  funding  requests  and  requirements  information 
through  electronic  submission  of  configuration  management  information.  Configuration  management 
files  of  existing  and  planned  capabilities  will  allow  more  precise  estimates  of  required  funding  and 
equipment  provisioning  when  bearer  system  changes  are  being  planned.  When  funding  cuts  or  transfers 
of  claimancy  take  place,  configuration  management  files  will  permit  more  precise  estimates  of  the  effects 
of  cost-cutting  or  transfer  of  responsibility. 

GLOBIXS  maintenance  will  be  done  primarily  by  contract  personnel  because  most  GLOB  DCS 
bearer  service  and  CPE  will  be  contractor-owned  and  maintained.  Good  configuration  management 
practice  (and  associated  accounting  management,  discussed  below)  will  reduce  costs  of  contractor 
maintenance  by  allowing  bidders  to  estimate  more  precisely  the  staffing,  equipment,  and  material  costs 
they  will  incur.  Configuration  management  (and  associated  fault  management,  discussed  below)  will 
help  eliminate  “finger  pointing”  across  interfaces  by  providing  precise  descriptions  of  responsibility 
domains,  and  technically  correct  descriptions  of  interface  performance  characteristics.  Configuration 
management  and  accounting  management  processes  will  also  help  the  government  accurately  evaluate 
the  performance  and  cost  of  contractor  maintenance. 

GLOBIXS  operation  also  will  be  a  contractor  responsibility  in  most  cases.  CCC  watch  personnel 
(and  personnel  at  other  GLOBIXS  subscriber  sites)  will  require  the  capability  to  use  performance 
management  processes  (discussed  below)  to  “look  over  the  shoulder”  of  contractor  personnel,  providing 
visibility  into  communication  system  operation.  In  most  cases,  this  visibility  will  be  to  monitor,  not  to 
intervene  in,  system  operation.  In  exceptional  cases  (such  as  natural  disaster),  CCC  and  GLOBIXS  site 
personnel  will  need  to  use  configuration  management,  performance  management,  and  fault  management 
processes  in  coordination  to  give  direction  to  contractor  operation  centers.  Even  during  routine 
operation,  good  configuration  management  and  performance  management  capability  will  allow  CCC 
and  GLOBIXS  site  personnel  to  see  clearly  the  status  of  their  communications  and  the  source  of  problems 
and  the  ability  to  compensate  through  operational  procedures  (such  as  shifting  operational  responsibility 
to  an  alternate  site)  if  communication  problems  cannot  quickly  be  corrected. 


TADIXS  Use  of  Configuration  Management 

Communication  planners  will  use  configuration  management  to  prepare  CSS  connection  plans 
for  use  in  TADIXS  operations.  These  plans  are  electronically  prepared,  coordinated,  and  disseminated 
assuring  all  affected  sites  provide  required  services.  Ships  and  NCTS  stations  will  provide  site 
configuration  management  information  through  the  administrative  chain  of  command  for  use  by 
operational  planners  preparing  CSS  connection  plans. 

Modernization  planners  will  use  configuration  management  to  support  the  planning  and 
execution  of  the  Fleet  Modernization  Program  (FMP)  and  related  shore  modernization  projects.  By 
knowing  equipment  capabilities  and  configuration,  Navy  staff  FMP  and  Naval  Computer  and  Telecom¬ 
munications  Command  (NCTC)  planners  can  accurately  estimate  funding  requirements.  To  optimize 


The  Copernicus  Architecture  •  8  A-3 


this  modernization  planning,  configuration  management  processes  will  require  the  capability  to  relate 
modernization  programs  to  fleet  operational  employment  (information  developed  by  employment 
scheduling  mechanisms  in  the  CCC). 

When  operational  planners  perform  time-sensitive  force  planning  under  the  Joint  Operational 
Planning  and  Execution  System  (JOPES),  they  will  use  configuration  management  to  determine  the 
communication  capabilities  of  units  being  considered  for  use  in  a  crisis  or  contingency.  Interoperability 
can  be  assured  by  selecting  ships  and  aircraft  with  appropriate  capability,  and  requirements  for  costly 
augmentation  can  be  averted  by  a  clear  understanding  of  the  operating  forces’  configuration. 

Maintained  at  all  echelons  will  use  configuration  management  to  plan  effectively  and  will 
execute  planned  maintenance  and  demand  maintenance  actions  in  support  of  operational  requirements. 
Material  requirements,  test  equipment,  and  personnel  skill  requirements  can  be  estimated  more 
accurately.  Part  stocks,  test  equipment  suites,  and  personnel  training  plans  can  be  adjusted  appropriately 
by  timely  and  accurately  updating  configuration  management  at  each  unit.  In  some  cases,  configuration 
management  can  show  that  accelerating  (or  delaying)  a  modernization  project  can  save  money  in  repair- 
part  stocking  and  personnel  training  actions. 

Operators  can  use  systems  more  effectively  by  having  access  to  more  precise  configuration 
management  information.  The  CSS  connection  plan,  a  successor  to  the  current  communication  plan,  is 
itself  a  configuration  management  file  that  shows  how  systems  are  to  be  used  operationally  at  a  particular 
time  or  in  a  specific  mission.  Operators  then  can  use  performance  management  to  assess  effectively  how 
well  the  pre-planned  connection  plan  is  serving  the  mission  or  how  an  alternative  connection  plan  could 
be  developed.  Configuration  management  information  will  help  eliminate  ambiguity  in  the  operational 
coordination  of  communications,  reducing  confusion  that  sometimes  develops  when  personnel  from 
different  FLTCINC  headquarters  or  personnel  from  different  Services  coordinate  communication 
operations. 


PERFORMANCE  MANAGEMENT 

Performance  management  mechanisms  monitor  the  functioning  of  communication  subsystems, 
collect  statistics,  provide  alerts  when  performance  exceeds  prescribed  bounds,  and  support  operator 
assessment  of  system  capability  against  mission  requirements. 


GLOBIXS  Use  of  Performance  Management 

Planners  will  use  historical  performance  management  information  (primarily  statistics)  to  assess 
how  effectively  GLOBIXS  are  supporting  operational  information  exchange  requirements.  They  also 
will  use  performance  management  information  to  more  intelligently  plan  for  and  advocate  funding  for 
communication  subsystem  improvement  programs. 

Maintainers,  as  noted  in  connection  with  configuration  management,  will  be  primarily  contractor 
personnel.  They  will  use  performance  management  as  an  indicator  of  the  requirement  for  demand 
maintenance.  Performance  management  information  will  also  help  government  and  contractor  GLOBIXS 
maintenance  personnel  optimize  spare  parts,  test  equipment,  and  personnel  skill  requirements. 
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Operators  will  be  the  principal  beneficiaries  of  performance  management  capability.  Opera¬ 
tional  users  will  not  have  to  depend  on  a  small  staff  of  trained  communicators  at  a  CCC  or  GLOBIXS 
node  to  monitor  and  control  communication  services  because  performance  management  information 
will  be  accessible  through  the  Fleet  All-Source  Tactical  Terminal  (FASTT)  HML  Communication  status 
will  be  available  at  any  workstation  and  to  any  operator.  Operators,  therefore,  will  have  visibility  into 
the  services  their  software  veneer  is  accessing  and  increased  confidence  that  they  can  understand  and  (if 
necessary)  control  the  communications  required  to  execute  their  mission. 


TADIXS  Use  of  Performance  Management 

TADIXS  planners  will  use  the  results  of  performance  management  statistical  monitoring  to 
analyze  how  well  communication  services  supported  execution  of  recently  completed  missions.  TTiey 
will  be  able  to  analyze  how  well  user  information  transfer  requirements  were  supported  and  improve 
planning  for  subsequent  missions.  Planners  may  be  able  to  use  modeling  and  simulation  techniques  to 
analyze  alternative  ways  of  satisfying  the  requirements  that  were  presented  in  a  mission  and  significantly 
improve  the  CSS  connection  plan  that  would  be  used  for  subsequent  missions  of  that  type.  Planners  also 
will  be  able  to  use  performance  management  statistics  to  advocate  requirements  intelligently  for 
modernization  or  updates  to  communication  mechanisms. 

Maintained  will  use  performance  management  to  enhance  system  availability.  During  a 
mission,  maintenance  personnel  will  be  able  to  see  areas  of  degraded  performance  and  initiate 
maintenance  action  if  appropriate  or  necessary.  After  a  mission,  site  and  administrative  chain  of 
command  personnel  will  review  system  performance  to  determine  if  changes  in  spares  stock,  mainte¬ 
nance,  or  training  policy  could  improve  performance.  Performance  information  will  be  particularly 
useful  to  software  support  activities,  because  they  will  be  able  to  understand  better  the  operational 
environment  in  which  software  operates. 

TADIXS  operators,  like  GLOBIXS  operators,  will  have  the  greatest  benefit  from  performance 
management  Naval  personnel  have  direct  responsibility  for  operation  of  TADIXS  and  require  direct 
access  to  information  about  system  performance.  Current  systems  require  trained  communications 
personnel  (usually  Radioman  or  Communication  Technician  [Operator]  [CTO]  ratings)  to  perform  this 
function  by  interacting  directly  with  the  front  panels  of  the  many  equipment  components  making  up 
digital  systems.  This  process  requires  many  people,  and  each  must  be  trained  to  evaluate  the  information 
on  the  equipment  front  panels.  This  process  effectively  is  hidden  from  people  who  use  communications 
systems,  because  it  takes  place  in  radio  room  spaces.  Moreover,  RM/CTO  personnel  use  language  quite 
different  from  the  language  of  communication  system  users. 

Some  operational  users,  however,  have  responsibility  for  coordinating  not  only  the  information 
flow  among  user  processes,  but  also  the  supporting  communications.  Examples  of  these  operational 
users  are: 


•  The  Force  Track  Coordinator  (FTC)  who  is  responsible  for  coordinating  operation  of  Link  11,  Link  14,  and  Joint 
Information  Distribution  System  (JT1DS)  as  well  as  enforcing  force  information  management  policy;  and 

•  The  Force  Over-the  Horizon-Track  Coordinator  (FOTC),  who  is  responsible  for  coordinating  operation  of  over-the- 
horizon  targeting  (OTH-T)  communication  systems  in  addition  to  enforcing  OTH-T  fusion  and  track  management 
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When  communication  conditions  are  unstable,  each  of  these  watch  positions  spends  a  significant 
amount  of  time  monitoring  communication  indications  and  interacting  with  radio  room  personnel  to  the 
detriment  of  their  information  management  duties. 

By  contrast,  performance  management  mechanisms  presented  at  the  work  stations  used  for  AAW 
track  management  and  OTH-T  data  fusion  will  allow  the  FTC  or  FOTC  to  pay  little  attention  to 
communication  performance.  Performance  management  mechanisms  can  be  represented  as  simply  as 
a  green,  yellow,  or  red  box  in  one  comer  of  the  screen  denoting  satisfactory,  marginal,  or  unsatisfactory 
communication  system  performance. 

If  the  CSS  connection  plan  has  provided  adequate  access  to  media  for  the  AAW  or  OTH-T 
service,  the  performance  management  box  will  stay  green  so  long  as  the  service  operates  without  fault 
or  problem.  Should  unanticipated  problems  or  operational  conditions  develop,  however,  the  CSS  user 
services  (described  below)  should  provide  continuing  service  for  at  least  the  minimum  essential 
information.  Should  human  intervention  be  necessary,  fault  management  (discussed  below)  will  give 
a  common  presentation  of  the  problem.  Operational  user  and  RM/CTO  personnel  will  use  performance 
management  capability  as  a  common  reference  of  what  the  situation  is,  and  configuration  management 
will  give  a  common  understanding  of  what  can  be  done. 


FAULT  MANAGEMENT 

Fault  management  is  an  extension  of  both  performance  management  and  hardware  fault 
indicators.  Performance  management  sets  thresholds  of  service  operation  (e.g.,  delay,  queue  size)  that 
will  trigger  fault  management  if  thresholds  are  violated.  Hardware  fault  indicators  also  will  trigger  fault 
management  Some  fault  management  actions  may  be  a  simple  trouble  report  for  maintenance  action 
and  operator  information.  Other  fault  management  actions  may  involve  days  of  restoral  activity. 


GLOBIXS  Use  of  Fault  Management 

Planners  will  use  GLOBIXS  fault  management  after  the  fact.  They  will  evaluate  the  causes  of 
faults  and  evaluate  action  taken  to  restore  service  (if  an  interruption  occurred).  Planners  will  examine 
performance  management  to  determine  if  service  requirements  were  appropriate  and  will  examine 
configuration  management  information  to  determine  if  adequate  redundancy,  spares,  test  equipment,  and 
trained  personnel  were  in  place  to  effectively  deal  with  the  fault.  Planners  also  will  review  fault 
management  history  files  to  determine  trends  and  may  use  modeling  and  simulation  capabilities  to 
project  future  fault  management  requirements. 

As  a  result  of  this  activity,  planners  may  work  up  proposed  changes  to  communication  bearer 
services  or  other  segments.  The  configuration  management,  performance  management,  and  fault 
management  information  used  to  develop  the  proposed  changes  will  be  accessible  to  higher  echelons  so 
the  adequacy  of  the  proposed  changes  can  be  assessed  and  cost  estimates  confirmed. 

Contractor  personnel  responsible  for  planning  will  be  able  to  articulate  proposed  changes  more 
clearly  and  factually  in  contract  to  the  government,  and  government  will  be  able  to  evaluate  the  substance 
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of  the  proposed  change  more  easily.  Both  contractor  and  government  participants  will  be  able  to  control 
cost  more  effectively  by  having  a  clear  picture  of  fault  management  history. 

Maintainers  will  be  a  principal  user  of  fault  management  in  real  time.  Rather  than  receiving 
ambiguous  trouble  reports  from  human  operators  who  may  not  have  an  opportunity  to  consider  all  the 
factors  involved  in  a  hardware  problem,  maintainers  will  be  able  to  look  at  the  system-level  information 
associated  with  a  particular  fault  This  will  result  in  more  timely,  cost-effective,  and  efficient  action  to 
respond  to  the  faulL  Fault  management  may  also  help  avoid  unnecessary  overtime  charges  that  result 
when  the  wrong  maintenance  person  is  called  to  correct  a  problem.  It  can  also  reduce  delay  in  getting 
the  most  appropriately  trained  person  to  address  the  problem. 

Operators  will  benefit  in  the  following  ways: 

•  First,  when  a  performance  management  threshold  is  violated,  operators  will  be  able  to  quickly  assess  if  a 
hardware  or  software  fault  has  caused  the  problem;  and 

•  Second,  operators  will  be  able  to  focus  full  attention  on  restoring  service  (if  CSS  multiple  resource  access  has 
not  provided  adequate  service  automatically)  rather  than  spending  time  diagnosing  the  problem  and  writing 
a  clear  and  factual  trouble  report 

Operational  users  of  GLOBIXS  services  will  benefit  from  fault  management  by  getting  clear  and 
unambiguous  information  about  what  faults  exist  and  (by  the  coordination  of  configuration,  perfor¬ 
mance,  and  fault  management  mechanisms)  the  effect  of  the  faults  on  system  capability.  This  will  help 
operational  users  continue  working  the  operational  problem  rather  than  being  required  to  focus  on 
communication  faults. 


TADIXS  Use  of  Fault  Management 

TADIXS  planners  and  maintainers  will  use  fault  management  for  the  same  purposes  that  planners 
and  maintainers  of  GLOBIXS  will  use  it.  A  significant  difference  is  that  TADIXS  planners  and 
maintainers  will  be  able  to  affect  change  more  quickly  in  many  cases.  Parts  can  be  shifted  quickly  from 
one  unit  to  another  to  effect  repair,  test  equipment  can  be  cross-decked,  and  trained  personnel  can  be . 
provided  quickly  in  response  to  technical  assistance  requests.  As  with  contractor-provided  GLOBIXS 
services  however,  there  are  costs  associated  with  these  actions.  Fault  management  information  will 
allow  both  GLOBIXS  and  TADIXS  planning  and  maintenance  personnel  to  avoid  fault-related  costs 
through  more  accurate  management  information  on  faults. 

TADIXS  operators  also  will  benefit  in  the  same  way  GLOBIXS  operators  benefit.  This  is  more 
critical  in  the  tactical  environment  because  a  small  number  of  RM/CTO  personnel  will  be  dealing  with 
many  urgent  communication  support  matters.  Clear,  consistent,  fault  management  information  will 
reduce  response  times  (although  in  most  cases,  CSS  resource  sharing  and  multiple  media  access 
mechanisms  will  eliminate  requirement  for  operator  action).  Fault  management  will  help  enhance 
training,  because  operators  will  no  longer  be  required  to  integrate  information  from  several  pieces  of 
equipment  to  deduce  the  cause  of  a  problem. 
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TADIXS  operations  controllers  at  the  Battle  Group  and  Batde  Force  level  will  experience  an 
even  more  significant  benefit  These  personnel,  who  will  be  watch  standers  in  the  SEWC  organization, 
may  not  be  RM  or  CTO  ratings.  They  will  depend  on  fault  management  information  to  assess  the  effect 
of  a  communication  system  fault  on  Battle  Group  or  Battle  Force  operations.  In  many  cases,  CSS 
multiple  media  access  will  preclude  a  serious  degradation  —  the  SEWC  operator  will  simply  note  that 
a  fault  has  occurred.  In  other  cases,  the  SEWC  operator  will  use  fault  management  information  to  invoke 
assistance  from  the  force  material  control  officer  or  force  electronic  material  officer  to  ensure  that  a 
serious  casualty  is  given  priority  attention. 

TADIXS  users  also  will  benefit  from  fault  management.  In  connection  with  performance 
management,  we  showed  that  the  FTC  and  FOTC  would  use  information  presented  at  their  TCC 
workstations  to  monitor  operation  of  supporting  communication  services.  Similarly,  these  watch 
personnel  will  receive  fault  management  reports  and  monitor  (when  necessary)  restoration  activity. 


SECURITY  MANAGEMENT 

Security  management  features  provide  access  control,  trust  in  the  functioning  of  key  processes, 
and  special  features  such  as  cryptographic  key  management.  Security  management  also  controls  some 
important  configuration  management  functions.  For  example,  security  management  would  assure  that 
only  an  authorized  person  could  set  up  or  tear  down  services,  preventing  an  unplanned  service  blockage. 


GLOBIXS  Use  of  Security  Management 

Planners  and  maintain  ers  of  GLOBIXS  will  use  security  management  for  a  number  of  purposes. 
There  will  be  periodic  assessments  of  security  requirements,  inspections  to  ensure  that  physical  and 
information  security  requirements  are  met,  and  assessments  of  potential  compromise  when  a  potential 
violation  is  detected.  Security  management  will  provide  more  accurate  and  reliable  records  of  security 
activity  than  current  paper  records  provide. 

A  Department  of  Defense  (DOD)  requirement  for  security  management  that  is  somewhat  unique 
is  the  management  of  communication  security  (COMSEC)  processes  and  keying  material.  Planners  will, 
in  conjunction  with  the  design  of  updated  or  expanded  services,  express  requirements  for  COMSEC 
processes  (which  may  be  stand-alone  equipment  or  embedded  firmware  in  GLOBIXS  communication 
servers),  and  keying  material.  Planners  and  maintainers  will  supervise  installation,  testing,  and 
activation  of  new  capabilities.  Information  security  managers  (similar  to  the  current  COMSEC 
custodian)  will  plan  for  use  of  key  and  ensure  that  keying  material  is  available  to  GLOBIXS 
communication  servers.  To  the  maximum  extent  possible,  red  (unencrypted)  key  should  never  be 
accessible  to  personnel.  In  addition,  it  is  a  Copernicus  requirement  that  GLOBIXS  communication 
servers  should  manage  real-time  use  of  key  through  the  Classic  Lightening  key  distribution  techniques. 

Planners  will  use  security  management  applications  to  devise  information  management  doctrine 
for  the  CCC  and  TCC,  ensuring  that  incoming  information  is  routed  to  the  correct  user.  Security 
management  planning  also  will  ensure  that  TCC-imposed  requirements  for  the  immediate  handling  of 
Case  1  and  Case  2  data  are  met 
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Operators  will  interact  with  security  management  routinely.  The  site  Communication  Officer 
will  maintain  access  control  to  GLOBIXS  communication  servers  and  will  qualify  personnel  to  perform 
operations  on  the  communication  servers.  Watch  personnel  will  depend  on  trusted  computing  base 
processes  to  reliably  route  information  to  the  intended  recipient,  segregate  information  streams  by 
classification  level  and  need-to-know,  and  verify  subscriber  authorization  to  access  services.  Watch 
personnel  will  manage  key  when  necessary  and  monitor  the  operation  of  trusted  computing  base 
processes  to  manage  key  routinely. 


TADIXS  Use  of  Security  Management 

TADIXS  planners  will  have  much  greater  interaction  with  security  management  They  will  use 
security  management  information  from  pastoperationsto  preparer  CSS  connection  plans  for  upcoming 
operations.  They  will  use  security  management  planning  capability  to  ensure  that  the  necessary  key  is 
in  place  to  support  operational  requirements  and  to  plan  subnetwork  sizes  to  ensure  that  appropriate 
crypto  net  sizes  are  observed.  As  mission  requirements  change  and  force  composition  changes,  planners 
will  revise  information  handling  and  key  management  plans  to  accommodate  the  changing  situation. 
Upon  completion  of  the  mission,  planners  will  use  the  security  management  reporting  capability  to  assess 
the  effectiveness  of  security  management  and  improve  planning  for  subsequent  missions. 

Maintainers  will  comply  with  security  management  policy  and  will  intervene  when  hardware 
faults  to  security  equipment  are  observed.  Operators  of  TADIXS  will  use  security  management 
processes  in  the  same  way  that  GLOBIXS  operators  use  them. 


ACCOUNTING  MANAGEMENT 

Accounting  management  provides  routine  “bookkeeping”  services.  Not  all  of  these  are  related 
to  cost  accounting.  The  functioning  of  performance  management,  for  example,  depends  on  collection 
of  statistics  by  accounting  management. 


GLOBIXS  Use  of  Accounting  Management 

GLOBIXS  planners  will  use  accounting  management  to  analyze  and  predict  costs  of  GLOBIXS 
operation.  In  conjunction  with  other  network  management  processes,  accounting  management  will  help 
planners  estimate  the  costs  of  GLOBIXS  service  updates  or  expansions.  When  Navy  policy  permits  or 
requires  user  billing  for  GLOBIXS  services,  accounting  management  will  provide  accurate  and  timely 
information  for  application  programs  that  handle  billing  and  collection. 

GLOBIXS  maintainers  will  use  accounting  management  processes  to  supplement  manually 
collected  maintenance  information.  Accounting  management  will  provide  information  about  how  long 
a  hardware  device  or  software  process  operated  prior  to  the  occurrence  of  a  fault.  It  also  will  provide 
information  such  as  subscriber  and  resource  usage  of  hardware  and  software  that  could  help  in 
reconstructing  fault  scenarios. 
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GLOBIXS  operators  will  use  accounting  management  reporting  features  to  observe  statistics 
concerning  system  use.  Accounting  management  will  support  routine  reports,  such  as  number  of 
information  units  handled  or  calls  processed,  that  are  currently  reported  by  manual  means. 


TADIXS  Use  of  Accounting  Management 

TADIXS  planners,  maintainers,  and  operators  will  use  accounting  management  in  a  similar  way. 
Maintenance  support  features  will  be  the  principal  benefit  for  TADIXS  users. 
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ANNEX B 

TADIXS  BEARER  SERVICES 


The  following  descriptions  expand  on  information  in  Chapter  6  regarding  existing  and  planned 
bearer  systems  that  Copernicus  TADIXS  will  use. 


SATELLITE  COMMUNICATION  (SATCOM)  BEARERS 

TADIXS  (except  for  Force  Operations  TADIXS  services  within  a  Battle  Group  or  amphibious 
ready  group)  are  heavily  dependent  upon  satellite  bearers.  The  Navy  expects  to  lease  commercial 
satellite  communication  bearers  through  the  Defense  Commercial  Contracting  Office  (DECCO). 
Military  satellite  communication  (MILS  ATCOM)  bearers  are  DOD  resources  to  be  used  as  allocated  by 
the  unified  commander. 


UHF SATCOM 

Networks  currently  operating  that  are  precursors  to  the  Copemican  TADIXS  use  UHF  SATCOM. 
Navy  policy  currently  prohibits  the  use  of  UHF  SATCOM  for  shore-to-shore  connectivity  (GLOBIXS 
service)  due  to  the  shortage  of  UHF  SATCOM  space  resources  and  availability  of  SHF  SATCOM  and 
commercial  SATCOM. 

Other  considerations  in  the  use  of  UHF  SATCOM  are:  All  Navy  combatant  ships  and  submarines 
(and  most  support  ships)  have  UHF  SATCOM;  requirements  have  been  stated  for  naval  aircraft  to  have 
UHF  SATCOM,  and  some  planning  is  going  forward  to  provide  this  capability;  and  all  DOD  tactical 
forces  have  some  UHF  SATCOM. 

Joint  Chiefs  of  Staff  policy  requires  UHF  SATCOM  users  (except  for  human  portable  terminal 
users)  to  employ  demand  assigned  multiple  access  (DAMA)  in  accessing  UHF  SATCOM  by  1996. 
DAMA  permits  as  many  as  22  user  network  requirements  to  be  satisfied  on  one  25  kHz  transponder. 

UHF  SATCOM  is  relatively  easy  to  use,  and  earth  terminals  are  relatively  inexpensive.  UHF 
SATCOM  space  segment  is  less  expensive  than  SHF  or  EHF  to  build,  launch,  and  maintain  on  orbit. 

UHF  SATCOM  links  can  be  blacked  out  for  hours  at  a  time  by  nuclear  bursts  and  are  considered 
virtually  unusable  in  an  intensive  nuclear  environment.  UHF  SATCOM  also  experiences  interference 
from  scintillation  coincident  to  high  solar  storm  activity. 

Current  Navy  applications  of  UHF  SATCOM  include  secure  voice,  Fleet  Broadcast,  the 
Submarine  Satellite  Information  Exchange  System  (SSIXS),  the  Common  User  Digital  Exchange 
System  (CUDIXS),  and  tactical  information  exchange  systems  such  as  OTCIXS  II  and  TADIXS  A. 
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SHF  SATCOM 

The  military  SHF  SATCOM  system  (Defense  Satellite  Communication  System  —  DSCS) 
operates  in  the  7  and  8  GHz  bands.  DSCS  bearer  service  is  appropriate  for  both  GLOB  DCS  and  TADIXS 
because  SHF  earner  signals  permit  large  bandwidth.  This  bandwidth  may  be  used  for  anti-jam  signal 
processing  (low  user  data  rates)  or  high  user  data  rates.  Navy  uses  both  services  for  fleet  operating  force 
support,  operating  nominal  9.6  kbps  services  through  a  processing  channel  and  64  kbps  through  a 
nonprocessed  transponder,  the  Navy  is  planning  to  expand  the  latter  category  of  service,  seeking  as  much 
as  1.544  Mbps  non-anti-jam  service  per  ship.  The  Navy  is  also  planning  to  install  SHF  SATCOM 
capability  on  most  combatant  ships,  with  initial  focus  on  aircraft  carriers,  amphibious  flagships,  and  flag- 
capable  cruisers. 

Other  considerations  for  use  of  SHF  SATCOM"  are:  SHF  is  less  susceptible  to  jamming  than 
UHF.  SHF  anti-jam  services  are  highly  resistant  to  uplink  jamming  attack.  Nuclear  air  bursts  degrade 
SHF  by  causing  interruptions  that  vary  in  length  depending  on  several  factors.  In  addition,  the  SHF 
uplink  signal  is  less  vulnerable  to  intercept  and  direction  finding  (DF)  by  tactical  units. 


EHF  SATCOM 

The  EHF  portion  of  the  frequency  spectrum  extends  from  30  to  300  GHz.  The  extensive 
bandwidth  available  at  EHF  frequencies  can  be  used  for  either  high  data  rate  transmission  or  for 
extremely  robust  anti-jam  communications.  The  currently  funded  EHF  SATCOM  programs  take  the 
latter  approach,  and,  consequendy,  user  data  rates  that  use  the  Satellite  Data  Link  Standard  wave  form 
through  EHF  SATCOM  are  2.4  kbps.  SDLS  EHF  SATCOM  is  primarily  oriented  toward  intra-batde 
group  TADIXS  service.  As  a  result  of  congressional  tasking,  FY90  and  FY91  work  has  commenced  to 
develop  a  medium  data  rate  (MDR)  capability  will  provide  some  anti-jam  performance  at  user  data  rates 
up  to  1.544  Mbps.  This  MDR  EHF  SATCOM  may  provide  GLOB  DCS  service. 

Other  considerations  concerning  EHF  SATCOM  are:  The  EHF  portion  of  the  spectrum  is  highly 
sensitive  to  atmospheric  attenuation,  the  narrow  beam  makes  interception  difficult,  and  EHF  is  less 
vulnerable  to  the  effects  of  nuclear  blackout  and  scintillation.  EHF  is  technically  susceptible  to  the 
geolocation  noted  in  connection  with  UHF  SATCOM  and  SHF  SATCOM,  though  there  are  consider¬ 
ations  that  make  these  techniques  more  difficult  at  EHF  frequencies. 

Navy  has  conducted  extensive  and  successful  test  and  evaluation  of  EHF  SATCOM  through  the 
Fleet  Satellite  Communications  Extremely  High  Frequency  Package  and  has  begun  limited  production 
of  shore,  ship,  and  submarine  terminals  as  part  of  the  NESP.  These  terminals  have  demonstrated  full 
interoperability  with  Army  and  Air  Force  terminals. 


Commercial  SATCOM 

Commercial  satellite  is  used  routinely  for  connectivity  among  the  shore  establishment,  but,  until 
recently,  it  had  only  limited  use  in  U.S.  Navy  tactical  operations.  Recent  highly  successful  application 
of  commercial  SATCOM  has  caused  a  broad-  based  review  of  its  suitability  driven  by  inadequate  military 
satellite  capacity  to  support  the  substantial  requirements  of  operations  in  some  geographic  areas  of  the 


The  Copernicus  Architecture  •  8A-13 


world.  Under  these  circumstances,  commercial  transportable  C-Band  and  Ku-Band  earth  terminals  are 
available  to  provide  leased  T-l  trunks  (1.544  Mbps)  to  interface  with  joint  and  component  tactical 
networks  in  theater. 

Commercial  carriers  that  are  potential  sources  of  T-l  commercial  satellite  service  include 
AT&T,  various  Bell  operating  companies,  GTE,  CONTEL,  PTI,  MCI,  INTELSAT,  US  Sprint,  ITT, 
COMSAT,  and  USTA.  In  special  applications,  the  Navy  has  utilized  INMARSAT  L-Band  (UHF) 
terminals  aboard  ship  to  enable  9.6  kbps  throughput  for  voice  and  data  services.  INMARSAT  has  also 
shown  that  it  can  be  applied  to  the  transmission  of  military  imagery.  The  Navy  also  has  used  the 
capabilities  of  the  least  MILS  ATCOM  commercial  satellite  and  is  considering  use  of  the  TELSTAR-G 
service  being  planned  by  AT&T  and  the  Iridium  service  being  planned  by  Motorola. 


BEYOND  LINE  OF  SIGHT  (BLOS)  BEARERS 

This  class  of  bearers  is  primarily  of  interest  in  connection  with  TADEXS .  They  provide  physical 
transmission  service  within  and  among  Battle  Groups.  Range  of  these  bearers  is  generally  about  1,000 
nautical  miles. 


High  Frequency  (HF)  Radio 

This  portion  of  the  frequency  spectrum,  2  to  30  MHz,  offers  communications  over  distances  of 
several  hundred  miles  (3  to  300  miles  groundwave,  skywave  to  1200  miles),  dependent  on  equipment 
used  and  conditions  of  operation.  Because  of  the  portion  of  the  spectrum  in  which  they  function  and  the 
modulation  applied  in  those  frequencies,  HF  systems  are  susceptible  to  atmospheric  absorption  and 
intercept,  and  are  the  systems  most  susceptible  to  jamming.  HF  skywave  communications  are  considered 
more  vulnerable  to  nuclear  blackout  than  other  frequencies,  but  ground  waves  are  minimally  affected . 
All  of  the  Services  use  HF  to  some  extent  and  all  Navy  ships  have  an  HF  capability.  Current  Navy 
applications  include  the  Fleet  Broadcast  (as  a  backup  to  satellite  systems)  and  ship-to-shore  teletype 
systems.  Current  Navy  HF  use  includes  single-channel  voice,  up  to  16  teletypewriter  circuits,  and  Link 
11.  Copemican  TADEXS  will  use  HF  to  a  limited  degree  because  the  poor  quality  of  transmission 
systems  and  narrow  bandwidth  provides  limited  capability.  The  Support  TADIXS  (e.g..  Logistic 
TADEXS,  Navy  Information  Exchange  System  [NAVIXS]  TADIXS)  may  use  HF  for  message  services. 


Very  High  Frequency  (VHF)  Meteor  Burst  Radio 

The  Navy  has  not  been  a  heavy  user  of  VHF  meteor  burst,  although  some  successful  demonstra¬ 
tions  have  been  made.  VHF  meteor  burst  is  essentially  a  direct-path  system  operating  between  30  mhz 
and  300  mhr,  using  meteor  trails  to  reflect  a  signal  between  points  150  to  1200  nautical  miles  apart. 

VHF  meteor  burst  has  proven  very  effective  in  transmitting  small  units  of  data  information 
between  two  points,  when  the  data  units  can  tolerate  delays  up  to  10  or  20  minutes.  One  successful 
demonstration  involved  having  ships  in  the  Hawaiian  operating  areas  transmit  own  ship  location  to  a 
shore  operating  control  center. 


8  A- 14  •  Annexes 


VHF  meteor  burst  is  not  suitable  for  voice  because  of  the  short  duration  of  meteor  trails  and 
scarcity  of  trails  that  will  support  2400  bps  narrowband  secure  voice.  Neither  is  it  suitable  for  high 
volume  data  exchanges  or  data  exchanges  that  require  very  rapid  service  because  it  is  difficult  to  predict 
when  a  meteor  trail  will  happen.  VHF  meteor  burst  is  not  suitable  for  networked  applications  of  simulcast 
or  multicast. 

It  is  unlikely  that  VHF  meteor  burst  will  be  used  extensively  for  Copemican  TADIXS.  In  a  few 
cases  (such  as  maritime  patrol  aircraft),  VHF  meteor  burst  may  be  applicable  to  low  data  rate  Force 
Operations  TADIXS  application. 


LINE  OF  SIGHT/EXTENDED  LINE  OF  SIGHT  BEARERS 

Line  of  Sight  bearer  services  are  applicable  to  TADIXS.  Range  of  these  systems  is  typically  0 
up  to  50  nm,  although  range  may  be  extended  up  to  300  nm  through  use  of  airborne  relays. 


VHF  Line  of  Sight  (LOS) 

Most  ships  have  VHF  LOS  capability.  Most  radios  in  the  VHF  range  are  single  channel,  non- 
hopped  equipment  used  primarily  for  coordinating  Naval  Gun  Fire  Support  (NGFS)  and  air-ground-air 
coordination  networks.  Some  ships  are  receiving  Single  Channel  Ground  and  Air  Radio  System 
(SINCGARS)  frequency-hopped  radios  for  NGFS  coordination,  but  SINCGARS  radios  are  difficult  to 
operate  in  the  shipboard  environment  of  high  RF  and  electromagnetic  interference  (RFI/EMI),  and  it  is 
extremely  difficult  to  simultaneously  operate  more  than  one  SINCGARS  radio  per  ship.  Naval  aircraft 
are  being  equipped  with  VHF  (SINCGARS  capable)  radios  to  be  used  for  close  air  support  coordination 
and  for  communication  with  other  services.  VHF  LOS  bearer  service  will  be  used  with  the  air-air,  air- 
ground-air  Force  Operations  TADIXS. 


UHFLOS 

The  UHF  frequency  band  is  from  300  to  3,000  MHz.  Due  to  the  flexibility  of  this  band,  distances 
achieved  vary  from  LOS  systems  that  communicate  for  5  to  100  miles  (terrain  dependent)  or  aircraft 
systems  that  communicate  for  up  to  300  nm.  UHF  systems  are  capable  of  high  quality,  reliable,  and  high 
capacity  transmissions  with  data  rates  of  2.4  kbps  or  higher.  It  is  widely  used  to  provide  secure/nonsecure 
voice,  record,  data,  and  facsimile  service  in  mobile  and  fixed  applications.  UHF  LOS  systems  can  be 
jammed,  but,  in  tactical  situations,  the  jammer  must  be  sufficiently  close  that  it  can  be  engaged  with 
CVBG  weapons.  Similarly,  UHF  LOS  systems  do  not  experience  significant  degradation  from  nuclear 
weapons  effects.  UHF  LOS  will  be  used  with  Force  Operations  TADIXS  in  many  roles. 


SHF  LOS/T  roposcatter 

Navy  tactical  communications  do  not  use  SHF  troposcatter  or  other  SHF  LOS  systems;  although 
an  SHF  backbone  troposcatter  with  a  nominal  range  of  35  nm  is  being  investigated  for  tactical  use. 
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WIRELINE  BEARERS 

These  bearers  connect  the  shore  establishment  and,  when  ships  and  submarines  are  in  port,  make 
connection  at  the  piers  where  the  vessels  are  berthed.  Current  wireline  bearers  are  copper  wire  in  most 
cases.  Very  few  wideband  bearer  services  are  in  use  at  naval  bases.  Commercial  service  providers  are 
installing  fiber  optic,  cellular  telephone,  and  other  modem  bearer  facilities  in  most  large  cities,  and  there 
are  some  transcontinental  and  transoceanic  services.  The  Navy  will  use  wireline  bearer  services  for 
GLOBIXS,  sharing  access  to  the  bearer  for  economy  and  efficiency.  When  ships  and  submarines  are 
in  port,  they  will  access  these  bearers  for  limited  TADIXS  service.  They  will  operate  Support  TADIXS 
message  services  in  port  just  as  they  operate  them  at  sea,  using  wireline  bearer  rather  than  S  ATCOM 
bearer  service. 

Base  Information  Transfer  System  (BEES)  will use  wireless  (e>g.,  fiber  optic)  services  to  provide 
transfer  of  voice,  data,  and  otherformats  within  naval  stations  with  interface  to  other  bearer  services  (e.g., 
DDN).  Ships  in  port  will  be  capable  of  BITS  access  for  multiple  services  (i.e.,  in  port  TADIXS  service, 
NAVIXS,  Imagery). 
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ANNEX C 
USER  SERVICES 


The  current  TADEXS/OTCIXS  was  developed  to  provide  communication  user  services  to  afloat 
units.  This  concept  has  continued  to  evolve.  The  Copernicus  goal  is  to  provide  a  broader  spectrum  of 
user  service  connectivity  to  afloat  units  through  the  flexible  and  adaptable  TADEXS  pillar. 

OTCIXS II  is  a  DAMA-capable  tactical  satellite  communications  network  for  command  and 
control  of  battle  group  operations  and  ship-to-ship,  ship-to-shore,  and  shore-to-shore  exchange  of  track 
data,  operational  note  messages,  and  data  files  supporting  over  the  horizon  targeting  (OTH-T).  The 
mission  of  the  system  is  to  provide  dependable,  beyond  line-of-sight  communications  among  surface, 
sub-surface,  and  shore  stations  on  a  near-real-time  basis.  In  the  current  situation,  the  submarine  OTCIXS 
operates  as  a  separate  service  from  thesurface-GTCIXS',  but  both  operate  via  the  Fleet  Satellite 
Communications  (FLTSATCOM)  system. 

Important  differences  exist  between  the  current  OTCIXS  II  and  a  Copemican  Force  Operations 
TADIXS.  OTCIXS  II  occupies  a  fixed  time  slot  and  bandwidth  in  the  UHF  SATCOM  DAMA 
transmission  system.  A  Copemican  TADEXS  will  be  a  virtual  network  that  can  share  time  slots  and 
bandwidth  with  other  networks.  The  current  OTCIXS  II  is  capable  of  operating  through  UHF  SATCOM; 
it  has  no  SHF  SATCOM,  EHF  SATCOM,  or  HF  capability.  The  Copemican  TADIXS,  however,  will 
be  capable  of  multi-media  operation.  Units  operating  current  OTCIXS  II  require  a  specific  set  of  terminal 
equipment  to  subscribe,  but  the  Copemican  TADIXS  will  use  common,  modular  hardware  and  software 
from  the  CSS  Standard  Communication  Environment  (SCE).  Only  one  protocol  is  in  use  with  the  current 
OTCIXS  n,  and  that  protocol  does  not  provide  equally  good  service  under  all  network  loading 
conditions.  In  Copernicus,  the  TADIXS  will  be  capable  of  using  many  session,  network,  and  link 
protocols  as  appropriate  for  the  operational  situation.  Current  OTCIXS  II  requires  trained  operators  to 
interact  directly  with  several  pieces  of  equipment  at  each  site  when  troubleshooting  net  problems  but  the 
Copemican  TADIXS  will  be  operated  through  the  software  veneer  of  GOTS  HMI,  and  expert  system 
performance  aids  will  help  operators  perform  both  system  and  equipment  level  fault  isolation. 

The  principal  difference  between  current  OTCIXS  II  and  the  Copemican  TADIXS  is  that  the 
OTC  has  very  little  choice  in  how  OTCIXS  II  operates.  The  OTC  can  either  use  UHF  SATCOM  OTCIXS 
II  at  2400  bps  or  use  the  same  bandwidth  for  some  other  network.  The  Copemican  TADIXS  will  be 
capable  of  much  more  flexible  operation,  in  multiple  transmission  media,  with  many  alternative 
subnetwork  configurations.  As  shown  in  Chapter  6,  the  OTC  will  be  able  to  select  dynamically  how 
much  and  what  kind  of  Strike  TADIXS  and  ASUW  TADIXS  service  is  appropriate  for  the  operational 
situation. 

The  current  TADIXS  A,  another  precursor  of  Copemican  TADIXS,  is  designed  to  provide  a 
broadcast  of  tactical  data  processor  data-link  traffic  on  a  one-way  transmission  path  from  shore  sites  to 
fleet  cruise  missile  units.  Phase  IV  of  the  program  provides  redundant,  automated  gateways  at  all 
NCTAMS  and  at  the  Naval  Communication  Station  (NAVCOMMSTA)  Stockton,  increased  link 
throughput,  message  accountability,  and  improved  link  diagnostics.  Connectivity  is  provided  via 
FLTSATCOM  and  dedicated  terrestrial  paths. 

TADIXS  A  is  similar  to  the  Direct  Targeting  TADIXS  of  Copernicus,  in  that  it  provides  shore 
transmit  service  of  targeting  products.  Another  similarity  is  the  fact  that  the  theater  TADIXS  A 
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subnetworks  are  provided  internet  gateway  service  at  the  NCT  AMS  and  NA  V COMMSTA  S  tockton.  As 
with  OTCIXS  II,  however,  many  differences  exist  between  current  TAD EXS  A  and  the  Copemican 
Direct  Targeting  TADDCS.  One  important  difference  is  that  current  TAD  DCS  A  operates  in  a  system- 
high  classification  configuration,  but  the  Copemican  TADDCS  will  provide  cyptographic  segregation  on 
a  subnetwork  basis  and,  eventually,  within  subnetworks.  Another  difference  involves  the  nature  of  data 
transmitted,  for  TADDCS  A  is  used  primarily  to  transmit  character-oriented  track  summaries,  and  the 
Copemican  TADDCS  will  contain  much  more  data  information  exchange  traffic. 

Building  on  these  precursors,  it  is  possible  to  conceptualize  a  model  set  of  Copemican  TADDCS 
for  a  CVBG,  the  basis  for  analysis  within  this  concept.  Most  of  the  TADDCS  will  have  connectivity  to 
the  CCC  where  filtering  of  data  will  have  been  accomplished  to  preclude  duplicate  traffic  from  being 
forwarded  to  operating  units.  Within  the  CCC,  anchor  desks  are  delegated  control  over  the  TADDCS 
most  related  to  their  functions  by  the-taetical  eommandersrand  these  desks  enforce  operational 
guidelines  for  the  traffic  that  is  forwarded  to  sea.  Access  to  a  TADDCS  is  controlled  by  operational 
parameters  established  under  those  guidelines  and  implemented  by  communication  servers  within  the 
CCC. 


The  physical  layer  connectivity  to  the  operating  forces  will  be  accomplished  by  any  of  a  variety 
of  transmission  paths  available  at  the  time  and  will  be  influenced  by  availability,  traffic  loads,  nature  of 
the  requirement  to  communicate,  and  the  operational  situation.  The  tactical  commander  will  indicate  in 
the  CVBG  CSS  connection  plan  how  the  connectivity  should  be  used,  and  the  NCTAMS  will  provide 
TADIXS  service  in  accordance  with  the  connection  plan.  As  previously  stated,  the  link  can  be  either 
military  HF  radio,  UHF  SATCOM,  SHF  SATCOM,  EHF  S  ATCOM,  or  commercial  SATCOM.  At  the 
distant  end,  the  TADDCS  will  access  the  TCC  via  the  SEWC  and  the  TCC  LAN  to  provide  information 
to  the  various  staff  elements. 

As  discussed  in  Chapter  3,  the  formats  that  will  pass  via  the  TADDCS  are  varied  and  reflect  the 
intent  of  this  architecture  that  reliance  on  paper  messages  will  be  substantially  reduced. 
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PROGRAMMATIC  REQUIREMENTS 


SUMMARY 

The  preceding  four  pillar  chapters:  (chaps.  4-7}  described  the  architecture  from  an  operational  standpoint,  and 
Chapter  8  outlined  the  building  blocks  from  which  the  architecture  will  be  constructed.  This  chapter  describes 
programmatic  requirements,  niethodologies  by  which  we  intend  to  move  from  many  Cold  War  “stove-pipe”  systems  to 
thepost-Cold  WarCopemicus  Architecture.  The  programmatic  requirements  are  contained  within  the  annexes  following 
this  chapter  and  thenext.  Chapters  4  through9,  then,  represent  a  Phase!  (seelntroduction)  deUneatim  of  the  operational 
-requirements  to  implement  the  architecture.  in  Chapter  10,  we  will  discuss  the  implementation  strategy* 

The  establishment  of  Space  and  Electronic  Warfare  (SEW)  as  a  warfare  mission  area  (WMA)  by  CNO  in  1989 
represented  a  Navy  commitment  to  bring  together  the  elements  of  electronic  warfare,  C*I,  surveillance,  and  other  tactical 
and  strategic  assets  into  a  seamless  SEW  system.  To  do  SO  required  a  synthesis  of  many  existing  programs  and  technologies 
and  the  development  of  the  operational  doctrine  of  SEW.  The  task  was  not  an  easy  one,  and  it  is  not  yet  complete,  nor  will 
itbesoon.  Like  air  power  in  the  1930s,  SEW  isarevolution  in  naval  warfare  that  will  evolve  over  several  years,  perhaps 
requiring  a  decade  for  full  maturation.  It  is  clear,  however,  that  to  implement  SEW,  four  considerations  must  be  examined. 


First,  whatis  SEW  doctrinally — what  are  the  operational  elements  of  SEW,  and  what  are  its  tactical  and  strategic 
goals?  This  has  been  the  discussion  and  focus  of  several  conferences  since  SEW  was  established,  and  the  definition 
provided  in  Chapter  1  represents  the  current  consensus  arising  form  the  1991  SEW  Conference. 

Second,  who  is  SEW — what  kind  of  sailors  and  officers  must  we  develop  to  build  and  operate  the  SEW 
technologies  and  take  them  to  sea?  Like  the  SEW  doctrine,  this  is  also  under  intense  scrutiny  at  this  writing. 

Third,  what  is  SEW  technologically —  what  technologies  are  required  to  construct  a  strategic  and  tactical  SEW 
capability,  and  how  can  they  be  molded  into  a  SEW  system  that  can  be  operated  seamlessly?  This  is  really  a  two-part 
question: 

•  What  systems  related  to  SEW  exist  today,  and  how  do  they  relate  to  one  another  (i.c.,  what  is  the  SEW 
baseline);  and 

•  What  is  the  desired  SEW  system  (i.e.,  what  will  be  the  SEW  technological  architecture)? 

Finally,  what  is  SEW  programmatically —  how  do  we  migrate  the  existing  systems  toward  the  goal  architecture 
and  how  will  we  (and  who  will)  manage  the  migration? 

The  purpose  of  this  and  the  following  chapter  is  to  outline  some  answers  to  the  latter  three  questions  for  a  subset 
of  SEW—  the  Copernicus  Architecture.  Four  interleaved  efforts  that  will  bring  the  architecture  into  programmatic  fruition 
are  discussed.  The  first  section  describes  the  intended  movement  technologically  and  programmatically  from  many 
duplicative  and  splintered  “stove  pipe”  programs  to  a  functional,  end-to-end  series  of  pillars  constructed  from  standard 
building  blocks.  In  the  section  following  that,  we  will  discuss  the  OP-094  Program  Objective  Memorandum  (POM) 
Investment  Strategy  that  is  currently  underway  and  describe  its  methodology.  Next,  our  intentions  relative  to  manpower 
and  training  are  described.  Finally,  we  set  to  paper  our  Research,  Development  Test  and  Evaluation  (RDT&E)  issues. 
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DISCUSSION 

The  four  pillar  chapters  (chaps.  4-7)  de¬ 
scribed  the  architecture  from  an  operational 
standpoint,  and  chapter  8  outlined  the  building 
blocks  from  which  the  architecture  will  be  con¬ 
structed.  This  chapter  describes  programmatic 
requirements,  methodologies  by  which  we  in¬ 
tend  to  move  from  many  Cold  War  “stove-pipe” 
systems  to  the  post-Cold  War  Copernicus  Archi¬ 
tecture.  The  programmatic  requirements  are 
contained  within  the  annexes  following  this  chap¬ 
ter  and  the  next.  Chapters  4  through  9,  then, 
represent  a  phase  one  (see  Introduction)  delinea¬ 
tion  of  the  operational  requirements  to  imple¬ 
ment  the  architecture.  Chapter  10  provides  the 
implementation  strategy. 

COPERNICUS  AND  THE  SEW 
BASELINE  SYSTEM 

The  establishment  of  SEW  as  a  WMA  by 
Chief  of  Naval  Operations  (CNO)  in  1989,  rep¬ 
resented  a  Navy  commitment  to  bring  together 
the  elements  of  electronic  warfare,  C4l,  surveil¬ 
lance,  and  other  tactical  and  strategic  assets  into 
a  seamless  SEW  system.  To  do  so  required  a 
synthesis  of  many  existing  programs  and  tech¬ 
nologies  and  the  development  of  the  operational 
doctrine  of  SEW.  The  task  was  not  an  easy  one, 
and  it  is  not  yet  complete,  nor  will  it  be  soon. 
Like  air  power  in  the  1930s,  SEW  is  arevolution 
in  naval  warfare  that  will  evolve  over  several 
years,  perhaps  requiring  a  decade  to  full  matura- 


It  is  clear,  however,  that  to  implement 
SEW,  four  considerations  must  be  examined. 

First,  what  is  SEW  doctrinally —  what 
are  the  operational  elements  of  SEW,  and  what 
are  its  tactical  and  strategic  goals?  This  has  been 
the  discussion  and  focus  of  several  conferences 
since  SEW  was  established,  and  the  definition 
provided  in  Chapter  1  represents  the  current 
consensus  arising  from  the  1991  SEW  Confer¬ 
ence. 

Second,  who  is  SEW —  what  kind  of 
sailors  and  officers  must  we  develop  to  build  and 
operate  the  SEW  technologies  and  take  it  to  sea? 
Like  the  SEW  doctrine,  this  is  also  under  intense 
scrutiny  at  this  writing. 

Third,  what  is  SEW  technologically — 
what  technologies  are  required  to  construct  a 
strategic  and  tactical  SEW  capability  and  how 
can  they  be  molded  into  a  SEW  system  that  can 
be  operated  seamlessly?  This  is  really  a  two-part 
question: 

•  What  systems  related  to  SEW  exist  today,  and 
how  do  they  relate  to  one  another  (i.e.,  what  is  the 
SEW  baseline);  and 

•  What  is  the  desired  SEW  system  (i.e.,  what  will 
be  the  SEW  technological  architecture)? 

Finally,  what  is  SEW  programmati¬ 
cally —  how  do  we  migrate  the  existing  systems 
toward  the  goal  architecture,  and  how  (and  who) 
will  manage  the  migration? 
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The  purpose  of  this  and  the  following 
chapter  is  to  outline  some  answers  to  the  latter 
three  questions  for  a  subset  of  SEW —  the 
Copernicus  Architecture. 

SEW  TECHNOLOGY 


nologies,  and  different  programs.  In  FY  89-90, 
OP-094directedthe  SEWBaselineSystem  Study 
to  catalog  existing  and  planned  programs  and 
determine  how  they  interconnected  (or  did  not). 
This  is  also  a  large  task,  and  it  too  is  still  ongoing. 
It  answers  the  first  part  of  the  technology  ques¬ 
tion  posed  above. 


Let  us  return  to  the  discussion  in  Chapter 
1  about  SEW  as  a  system —  a  doctrinal,  organi¬ 
zational,  and  technological  “macro-system”;  it 
takes  all  three  to  construct  SEW.  Like  all  macro¬ 
systems —  even  those  intended  to  operate 
seamlessly —  SEW  has  operational  components 
andresulting  technological  subsystems  thatmake 
those  operational  goals  possible. 

Doctrinally,  SEW  encompasses  six  ma¬ 
jor  disciplines  (see  fig.  9-1)  some  of  which 
currently  have  different  sponsors,  different  tech- 


The  magnitude  of  the  SEW  baseline 
study,  which  includes  more  than  180  programs 
that  are  not  sponsored  by  OP-094  and  90  more 
that  are,  underscores  the  magnitude  of  the  tech¬ 
nological  task.  Constructing  (even  defining)  the 
desired,  ultimate  SEW  macro-system  will  not 
simply  be  a  task  of  engineering  it  correctly,  it 
will  require  a  strategy  to  bring  many  current  and 
planned  systems  together —  most  of  which,  as 
we  have  seen,  not  only  do  not  “belong”  to  OP- 
094,  many  do  not  belong  to  the  Navy. 


SEW  Doctrine 

CWC  | 


1 


SBWC  1 

1 — i — 1  :  • 

m  w 

1 

ESM/BCM/ECCM 

SK3NT  9GSBC  Surwtfknw 

Cfi 

SEW  Technology  Systems 

•  Command  and  Control 


•  Communications  and 
Computers 
(Information  Mgmt) 

•  Intelligence  Display  and 
Dissemination 


Figure  9- L  Relationship  Between  SEW  and  Copernicus 


9-4  •  Programmatic  Requirements 


The  effort,  then —  the  second  of  the  two 
technology  questions  above —  will  shift  from 
cataloging  to  bringing  existing  programs  and 
technologies  into  groups  of  like  operational  fo¬ 
cus —  subsystems  of  the  desired  SEW  macro¬ 
system — that  can  be  operated  together  to  achieve 
the  SEW  tactical  and  strategic  goals.  Indeed  this 
second  effort  is  underway  in  some  areas  simul¬ 
taneously  with  the  cataloging  effort  This  ap¬ 
proach  not  only  makes  good  technological  and 
programmatic  sense,  it  makes  common  sense. 
Much  like  a  car  that  is  designed  to  be  driven  by 
one  operator  but  is  manufactured  in  many  sub¬ 
systems  by  different  manufacturers  according  to 
an  overall  design ,  so  will  be  the  ultimate  SEW 
system. 

COPERNICUS  AS  A  SUBSYSTEM  OF  SEW 

Copernicus  is  such  a  design.  Like  the 
superset  SEW,  the  subset  C4I  components  of  the 
system  are  owned  by  organizations  far  and  wide: 
sensors  from  the  intelligence  community,  com¬ 
munications  backbones  from  the  Defense  Com¬ 
munications  System  (DCS),  and  a  host  of  inde¬ 
pendent  command  and  control  systems. 

The  Copernicus  “design”  is  an  architec¬ 
ture  in  the  truest  sense:  it  is  not  a  program  or  a 
system,  but  rather  a  context  for  them  and  a 
methodology  by  which  to  proceed.  Copernicus 
was  developed  simultaneously  with  the  SEW 
technology  baseline  study  because,  while  SEW 
doctrine  was  still  in  its  infancy,  it  was  apparent 
nonetheless  that  C4I  was  to  be  a  major  sub¬ 
system  of  SEW  and  that  subsystem  was  hemor¬ 


rhaging.  Moreover,  the  components  of  C4I,  a 
doctrinal  function  well  understood  for  decades, 
were  much  clearer  than  the  other  potential  sub¬ 
systems  of  SEW. 

The  second  and  third  subsystems  will 
likely  emerge  as  the  Electronic  Combat  sub¬ 
system,  which  would  encompass  strategic  and 
tactical  EW  and  command,  control  communica¬ 
tions,  computers  and  intelligence  (C4ICM),  and 
the  surveillance  subsystem,  which  probably 
would  include  the  surveillance  assets  themselves 
and  the  collection  management  infrastructure 
necessary  to  task  them  for  strategic  and  tactical 
missions. 

Once  these  subsystems  are  defined  as 
Copernicus  has  been,  the  overriding  technologi¬ 
cal  architecture  for  SEW  will  emerge.  Because 
of  the  nature  of  these  subsystems,  the  organiza¬ 
tional  infrastructure  will  follow  from  the  deci¬ 
sions  taken  in  defining  the  subsystems.  Finally, 
the  achievement  of  SEW  operationally  will  be 
to  achieve  the  doctrinal  framework —  putting 
the  key  in  and  turning  the  engine  on —  to  focus 
the  technology  for  the  mission.  The  develop¬ 
ment  of  the  SEW  fabric  will  depend  not  only  on 
the  fabric  pieces  themselves  but  also  on  the 
ultimate  macro-system  needed  to  mesh  SEW 
seamlessly.  That  goal  will  be  achieved  through 
three  broad  thrusts: 

•  The  development  of  a  SEW  Naval  Warfare  Pub¬ 
lication  currently  in  draft  in  OP-094  in  concert 
with  Second  and  Third  Fleet  efforts  to  develop 
SEW  tactical  memorandum  (TACMEMOs); 

•  The  continuing  effort  of  the  SEW  Baseline  S  tudy 
to  identify  the  subsystems  of  SEW;  and 
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•  The  implementation  of  the  first  of  those  sub¬ 
systems,  the  Copernicus  Architecture. 

In  the  remainder  of  this  chapter,  we  ad¬ 
dress  four  interleaved  efforts  that  will  bring  the 
architecture  into  programmatic  fruition.  The 
following  section  describes  the  intended  move- 
ment  technologically  andprogrammatically  from 
many  duplicative  and  splintered  “stove  pipe” 
programs  to  a  functional,  end-to-end  series  of 
pillars  constructed  from  standard  building  blocks. 
The  implementation  strategy  for  this  process  is 
described  in  Chapter  10.  In  the  section  follow¬ 
ing  that,  we  will  discuss  the  OP-094  POM  In¬ 
vestment  Strategy  that  is  cuirendy  under  devel¬ 
opment  and  describe  its  methodology.  Next,  our 
intentions  relative  to  manpower  and  training  are 
described.  Finally,  we  set  to  paper  our  RDT&E 
issues. 

STOVE  PIPES  TO  BUILDING  BLOCKS 

Programmatically,  Copernicus  conveys 
a  number  of  advantages  for  us:  common  stan¬ 
dards,  better  and  cheaper  logistics  through 
Planned,  Incremental  Modernization  (PIM),  and 
evolutionary  procurement,  to  name  three.  Per¬ 
haps  most  important,  however,  is  that  Copernicus 
as  an  architecture  gives  us  the  ability  to  define 
the  system  components  functionally  from  end- 
to-end.  Figure  9-2  shows  a  simplified  traffic 
flow  diagram  of  a  data  packet  delivered  from  a 
non-organic  sensor  to  an  afloat  platformi .  Fig- 


1  See  figs.  3-8, 9,  and  10  in  chap.  3  for  a  similar  view  from  a 
communications  perspective. 


ure  9-3  is  a  different,  but  similarly  functional, 
diagram  of  the  architecture. 

Once  we  are  able  to  describe  the  end 
product  in  functional  blocks  and  to  describe 
those  blocks  within  a  common  operating  envi¬ 
ronment  (see  chap.  8),  a  process  can  be  con¬ 
structed  to  move  from  today’s  many  vertical 
stove  pipe  systems  to  tomorrow’s  end-to-end 
systems.  The  methodology  for  doing  so  in¬ 
volves  five  steps. 

Step  1:  Copernicus  Building  Blocks 

The  first  step  in  the  process  is  to  develop 
engineering  models  of  the  Copemican  pillars  in 
detail  as  part  of  the  Phase  II  engineering  effort 
(see  Introduction  and  chap.  10).  The  diagrams 
(generically  shown  in  fig.  9-4)  will  provide  a 
detailed  engineering  template  from  end-to-end. 

Step  2:  Devolve  Existing  Programs 
to  Building  Blocks 

The  second  step  is  to  devolve  existing 
programs  into  potential  building  blocks  and 
select  the  “best  of  breed”  among  the  blocks 
suitable  for  use  in  the  architecture.  This  will 
necessarily  be  a  “cut-and-paste”  task.  Clearly, 
the  number  and  diversity  of  building  blocks  will 
vary  by  program.  Some  programs,  because  of 
the  systems  engineering,  others  (e.g..  Navy  Stan¬ 
dard  Teletype,  KG-84,  Combination  Radio)  may 
only  be  building  blocks.  For  comparative  pur¬ 
poses,  this  process  will  vertically  slice  existing 
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stovepipes  into  components  defined  in  Copemi- 
can  terms. 


ability,  feasibility  and  affordability. 
Affordability,  which  heretofore  has  been  the 


domain  of  programmatic  considerations  and  not 
“Best  of  breed”  analysis  will  necessarily  engineering  efforts,  is  a  legitimate  criterion  in 
involve  developing  engineering  criteria  of  suit-  the  step  of  the  process  because,  when  applied  to 
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Figure  9-4.  Functional  Blocks  of  a  Copernican  Pillar 


building  blocks  as  opposed  to  whole  programs, 
a  comparative  analysis  is  achievable  on  a  one- 
to-one  basis. 

Indeed,  this  is  one  of  the  great  benefits 
of  horizontal  architectures  over  stove  pipe  pro¬ 
grams.  Stove  pipes  can  only  be  compared 
against  other  stove  pipes  that  typically  are  not 
being  developed  to  meet  similar  requirements. 
Affordability  in  this  vein  is  a  POM  issue  not  a 
component  issue  because,  in  the  absence  of 
direct  comparison  by  function  and  requirement, 
there  is  only  the  question  of  whether  enough 
money  remains  in  the  POM  at  the  end  of  the 
process  for  all  (e.g.,  TACINTEL  vs  Mini-De¬ 
mand  Assigned  Multiple  Access  [DAMA],  or 
Joint  Tactical  Information  Distribution  System 
[JTIDS]  vs  OBU).  In  a  "horizontal"  compari¬ 
son,  however,  communications  processor  “A” 
from  program  “A”  can  be  compared  with  pro¬ 
cessors  “B”  through  “Z”  to  select  a  Navy 
standard  communications  processor. 


example,  there  will  likely  be  two  kinds  of  com¬ 
munications  processors  in  Copernicus —  an 
ashore  processor  and  an  afloat  processor  (i.e., 
DCS  versus  Communication  Support  System 
[CSS]).  Both  types  will  come  in  several  ver¬ 
sions;  for  example,  the  shore  processor  probably 
will  be  implemented  as  a  circuit  card,  in  a  work¬ 
station,  or  as  a  stand-alone  machine  depending 
on  size  of  node  and  other  considerations.  Figure 
9-5  illustrates  “best  of  breed”  selection. 

Step  3:  Overlay  Existing  Against  Required  Blocks 

The  resultant  existing  best-of-breed 
building  blocks  can  be  overlaid  against  the  de¬ 
sired  template.  Copernican  building  blocks  that 
could  not  be  identified  in  a  best-of-breed  are 
candidates  then  for  Research,  Development,  Test 
and  Evaluation  (RDT&E)  programs  (see  fol¬ 
lowing  for  a  discussion  of  anticipated  RDT&E 
issues). 


It  is  important  to  recognize  that  families 
of  building  blocks  will  arise.  To  continue  the 
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Figure  9-5.  "Best  of  Breed”  Selection 


Step  4:  Develop  Integrated  Logistics 
Support  Strategy  (ILS) 

The  next  step  is  to  develop  an  ELS  strat¬ 
egy  for  each  major  functional  block.  In  the  past, 
ILS  has  been  a  monolithic  process,  a  series  of 
steps  defined  across  the  board  for  system  com¬ 
ponents  with  little  regard  to  the  component  it¬ 
self.  Like  all  generalizations,  this  one  has  excep¬ 
tions,  and,  in  recent  years,  the  explosion  in 
electronics  has  attuned  the  acquisition  commu¬ 
nity  to  the  need  for  new  approaches.  However, 
breaking  the  back  of  steep  logistics  costs  is  a 
two-fold  process: 

•  Recognizing  the  need  for  both  system  ILS  and 
component  ILS,  and  recognizing  the  life  cycle 
support  varies  both  by  component  and  by  sys¬ 
tem.  In  component  terms,  the  generational  length 
for  a  workstation  today  is  probably  18  months; 


the  generation  foranantennamay  be  lOyears.  In 
system  terms,  ILS  should  be  considered  support 
for  the  system  integration  and  interfaces,  which 
is  quite  different  from  the  sum  of  its  components 
(see  fig.  9-6);  and 

•  Defining  new  criteria  for  ILS,  especially  in  OI 
components  that  are  electronics-intensive.  The 
criteria  should  not  be  mean-time-between-fail- 
ure  (MBTF),  which  today  typically  exceeds 
mean-time-before-obsolescence  (MTBO)  of 
many  components.  Use  of  MTBO  instead  of 
MBTF  can  lead  us  to  strikingly  new  ILS  strate¬ 
gies,  such  as  PIM  (see  fig.  9-7),  which  center  on 
technology  refreshment  techniques. 


Step  5:  Restructuring  Programs 

The  final  step  in  the  process  is  restructur¬ 
ing  programs.  This  will  be  a  complex  process 
occurring  over  a  Six  Y ear  Defense  Plan  (S  YDP) 
in  which  three  types  of  programs  will  emerge: 
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building  block  and  RDT&E  programs  which 
provide  raw  material  for  the  third  type,  pillar 
programs.  Two  of  the  three  types  of  programs 
will  contain  several  appropriations.  For  ex¬ 
ample,  the  eventual  implementation  of  the  Nor¬ 
folk  CCC  will  evolve  from  a  restructured  OSS 
program  that  will  draw  resources  from  several 


building  block  lines.  The  Norfolk  CCC  will 
require  Other  Procurement,  Navy  (OPN)  and 
Operations  and  Maintenance,  Navy  (0&M,N), 
but  little  RDT&E.  Building  block  programs 
(e.g.,  Desktop  Computer  Terminal  [DCT-2]) 
will  require  RDT&E,  OPN,  and  0&M,N.  It  is  a 
goal  of  the  architecture  that  implementation  will 


Not  MTBF,  Mean  Time  Before  Obsolescence 


Figure  9-7.  Planned,  Incremental  Modernization  (PIM) 
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result  not  from  a  Copernicus  program  per  se,  but 
from  a  realignment  of  existing  programs  into  the 
Copemican  mold.  Within  this  context  we  may 
find  it  necessary  for  near  term  (S  YDP)  enhance¬ 
ments  to  provide  interim  (pre-Copemicus/tran- 
sition)  fleet  upgrades. 

Figure  9-8  summarizes  this  Copernicus 
technological  and  programmatic  strategy  that 
will  be  conducted  over  several  POMs.  In  the 
section  below,  we  discuss  the  beginnings  of  that 
evolution,  the  OP-094  POM  94  Investment 
Strategy. 

•  STHPl:  Identify  Functional  Building  Blocks  (Hardware  & 

Software)  in  Copernicus  Pillars 

•STEP  2:  Devolve  Existing  Programs  to  Similar  Building  Blocks 

•  STEP  3:  Overlay  Existing  "Best  o£  BreedK  Against  Required 

Copemican  Blocks  (Shortfalls  -  RDT&E) 

Develop  System  and  Component iLS  Strategies 

•  STEP  S:  Restructure  Programs 

Figure  9-8.  Five-Step  Copernicus 
Technological  and  Programmatic  Strategy 

POM  94  INVESTMENT  STRATEGY 

POM  94  will  be  the  first  SEW  POM.  The 
investment  strategy  for  OP-094  is  currently  in 
development  and  will  involve  the  fusion  of  a 
series  of  decision  points  from  the  SEW  Baseline 
Study,  the  Copernicus  Project  Team,  and  OP- 
940.  The  Investment  Strategy  is  aimed  at  defin¬ 
ing  and  implementing  future  program  direction 
and  support,  for  Copernicus  component  sys¬ 
tems,  for  other  SEW  Baseline  programs  under 
OP-094  sponsorship,  and  for  personnel-related 
issues. 


The  investment  strategy  also  identifies 
R&D  efforts  that  are  needed  to  support  SEW  and 
Copernicus  implementation  (see  section  below 
on  R&D).  The  specification  of  R&D  efforts  is 
intended  to  be  used  by  the  Office  of  Naval 
Research,  Office  of  Naval  Technology,  and  Of¬ 
fice  of  Advanced  Technology  in  developing 
SEW  programs. 

As  mentioned,  the  SEW  investment  strat¬ 
egy  represents  a  fusion  of  the  recommendations 
from  the  Copernicus  analysis  and  those  from  the 
SEW  Baseline  analysis.  Beginning  with  archi¬ 
tectural  features  and  proceeding  to  system  selec¬ 
tions,  the  Copernicus  approach  is  “top-down”, 
and  is  designed  to  provide  a  new  approach  to 
defining,  designing,  and  implementing  OT  sys¬ 
tems.  The  SEW  investment  strategy,  based  on 
analyses  of  current  programs  and  systems,  is 
directed  at  providing  support  for  POM-94  delib¬ 
erations  about  SEW  and  the  Copernicus  sub¬ 
systems.  It  is  a  “bottom-up”  approach  oriented 
toward  assessing  programs  individually  vis-a- 
vis  a  defined  set  of  decision  points. 

Both  methods,  which  provide  a  check 
and  balance  against  each  other,  have  as  their  goal 
the  specification  of  ranked  sets  of  candidate 
systems  and  programs.  As  we  have  seen,  for  the 
Copernicus  approach,  the  analysis  is  carried  out 
separately  for  each  of  the  four  pillars.  For  each 
pillar  a  set  of  functions  is  defined  that  character¬ 
izes  the  major  activities  carried  out  under  that 
pillar.  For  each  function  within  the  pillar,  a  set 
of  specific  services  is  then  identified.  For  each 
of  these  services,  a  set  of  current  and  postulated 
systems  and  programs  is  ranked  according  to  the 
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degree  to  which  each  carries  out  the  services  (see 
fig.  9-9).  There  are  three  prioritized  ranking 
groups,  defined  as:  high  priority  systems,  sys¬ 
tems  requiring  restructuring,  and  systems  re¬ 
quiring  further  investigation. 

The  individual  service  results  for  a  given 
function  are  then  “rolled  up”  into  overall  results 
for  that  function,  and  the  results  for  all  functions 
within  a  pillar  can  be  “rolled  up”  to  characterize 
the  findings  for  that  pillar.  The  overall  results  at 
any  level  are  sets  of  systems,  ranked  by  virtue  of 
being  included  in  one  of  the  three  groups. 

The  goal  of  the  SEW  investment  strategy 
methodology  is  to  rank  candidate  systems.  For 
example,  one  approach  is  to  rank  systems  within 
each  of  four  OP-094  investment  categories: 
tactical  OI  andEW,  infrastructure  modernization 


and  automation,  space  and  surveillance,  and 
strategic  communications.  The  methodology 
works  similarly  in  prioritizing  within  the  four 
Copernicus  pillars.  For  the  SEW  investment 
strategy  methodology,  candidate  systems  or 
programs  are  assigned  to  the  appropriate 
investment  category  or  categories.  Each  system 
is  then  scored  in  accordance  with  the  degree  to 
which  it  conforms  to  the  Copernicus,  SEW,  and 
Programmatic  decision  points,  shown  in  figure 
9-10. 

The  scores  are  then  combined  to 
determine  amerit  value  for  that  system  within  its 
particular  investment  category.  The  systems 
within  each  of  the  investment  categories  can 
then  be  ranked  by  their  merit  values.  It  is  not 
presently  planned  to  rank  systems  across 
investment  categories.  As  indicated  above,  the 


Function: 

Service: 

Quality: 

Coverage: 

Applications: 

Utilities: 

Operating  Systems: 
Resources: 


Command  TADIXS 

Voice,  message,  graphics,  and  facsimile  exchanges 
Nominally  1  error  in  10,000  bits 
Global  (through  gateways) 

Communication  Support  System,  OSS,  NTCS-A 
Network  mgmt,  Directories,  Format  Xlation,  INFOSEC 
Navy  Tactical  Command  System  Afloat  O.S. 


Commercial  SATCOM  * 
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EHF  SATCOM  * 

SHF  SATCOM  ♦ 

UHF SATCOM  * 
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Base  Information  Transfer 
System 

Comms  Ashore 
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System 
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Figure  9-9.  Example  of  Copernicus  Program  Analysis 
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fundamental  issue  is  to  fuse  the  results  from  both 
of  the  methods  into  a  single  overall  strategy.  The 
Copernicus  strategy  builds  upon  the  12 
Copernicus  decision  points  (fig.  9-11),  and  the 
SEW  investment  strategy  extends  these  to  a  total 
of  28  decision  points  (figs.  9-12  and  9-13). 
Thus,  the  process  of  fusing  the  results  from  the 
two  methodologies  has  a  firm  foundation.  The 
fusion  task  will  be  completed  as  part  of  the  POM 
94  development. 

MANPOWER,  PERSONNEL,  AND  TRAINING 
(MPT)  STRATEGY 

An  essential  issue  regarding  the  imple¬ 
mentation  of  the  Copernicus  Architecture  is  the 
type  of  personnel  that  Copernicus  will  need. 


Technological  acquisition  and  automation  are 
hollow  investments  without  supporting  man¬ 
power  and  training.  The  quickest  way  to  guaran¬ 
tee  successful  implementation  of  the  architec¬ 
ture  will  be  through  advanced  planning  and 
preparation  in  the  MPT  arena. 

Program  evaluation,  investment  analy¬ 
sis,  and  acquisition  spending  should  all  take  into 
consideration  manpower,  which  is  the  Navy’s 
most  valuable  resource.  It  is  a  common,  though 
not  common  sense,  approach  to  buy  technology 
and  worry  later  about  the  cost  of  training  and 
manning  for  the  system.  All  too  often  this  results 
in  a  system  that  fails  to  meet  performance  and 
operational  standards.  The  lesson  learned  is  that 
manpower  and  training  are  as  important  to  logis¬ 
tics  as  software  support  or  spare  parts  programs. 


The  Copernicus  Architecture  •  9-13 


A  major  thrust  of  the  POM-94  Invest¬ 
ment  Strategy  is  developing  a  “new”  approach 
in  addressing  this  issue.  The  combined  issue  of 
manpower  and  training  is  now  a  key  decision 
point  in  assessing  all  SEW  systems.  The  basic 
assumption  for  MPT  planning  in  support  of 
SEW  is  that  implementation  of  the  SEW  and 
Copernicus  concepts  will  occur  with  no  net- 
growthofmanpowerortrainingresources.  Under 
the  investment  strategy,  systems  that  are  too 
MPN-  or  0&M,N  -  intensive  will  be  examined 
for  elimination  over  the  SYDP.  PIM  will  be¬ 


come  one  of  the  driving  forces  impacting  man¬ 
power  and  training  needs.  While  PIM  will 
provide  profit  incentives  to  industry  to  replace 
obsolete  equipment,  it  also  should  provide  in¬ 
centives  to  reduce  MPN  and  O&MN. 


ACHIEVE  SEW  B/L  MINIMUM  REQMTS 

Fj 

:  x> 

— 

MANDATED  PROGRAM 

II 

UNIQUE  CAPABILITY 

i 

HEALT^y 

II 

REDUCE  MANPOWER 

Figure  9-12.  SEW  Decision  Points 


While  the  quantity  of  our  work  force  is 
always  a  predominant  consideration  in  a  Navy 
of  shrinking  resources,  advanced  technology 
dictates  closer  examination  of  the  quality  of  the 
individuals  and  the  training  they  will  require. 
Four  major  manpower  and  training  thrusts  un¬ 
derlie  the  MPT  strategy: 
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•  The  quantity  of  manpower  available; 

•  The  anticipated  quality  of  those  individuals; 

•  Training  requirements;  and 

•  Human/systems  integration. 

Major  Thrusts  Underlying  the  MPT 
Investment  Strategy 

Navy  manpower  is  being  significantly 
reduced  across  the  SYDP.  As  the  number  of 
warfare  platforms  decreases,  the  shore  infra¬ 
structure  supporting  the  fleet  is  also  decreasing. 
OP-094-sponsored  MPN  alone  has  been  reduced 
by  22  percent  since  FY  90.  Current  assessments 
of  upcoming  POM  94  provide  strong  indications 
of  further  manpower  reductions  towards  the 
year  2000. 

In  such  an  environment,  each  new  and 
existing  SEW  system  must  be  evaluated  in  terms 
of  manpower  utilization  and  savings  potential. 
Our  Investment  Strategy  will  be  a  no-net  growth 
plan.  A  new  look  will  be  taken  at  MPN  and 
O&MN  intensive  systems,  and  new  technology 
and  new  manning  concepts  will  be  used  when 
possible.  Additional  manning  for  certain  com¬ 
ponents  of  the  Copernicus  Architecture,  such  as 
the  CCC,  will  have  to  be  realized  through  man¬ 
power  savings  in  other  areas. 

Once  the  Copernicus  Architecture  is 
clearly  defined  in  terms  of  actual  fleet/shore 
implementation,  modified  Hardware/Manpower 
(HARDMAN)  analyses  should  drive  the  sup¬ 
porting  manpower  requirements.  Existing  man¬ 
power  standards  will  no  longer  apply.  PIM, 
improved  MTBF,  and  more  “user  friendly” 


equipment  will  be  instrumental  in  achieving 
new,  and  most  likely  reduced,  manpower  re¬ 
quirements. 

To  ensure  that  our  people  have  the  “right 
stuff’  for  SEW  we  must:  1)  review  C4I  enlisted 
ratings  for  future  validity  and  skills  overlap,  2) 
impose  higher  qualifications  standards  for  C4I 
rating  accessions,  3)  modernize  training  cur¬ 
riculum  and  equipment,  and  4)  provide  for  ongo¬ 
ing/refresher  training  for  our  C4I  professionals. 

To  address  these  training  and  education 
needs,  we  must  start  by  envisioning  and  docu¬ 
menting  the  requirements  most  critical  to  the 
success  of  our  SEW  Navy  professionals,  includ¬ 
ing  identification  of  needed  skills,  new  duties, 
and  types  of  knowledge  required.  The  question 
of  new  ratings  and  Navy  Enlisted  Codes  (NECs) 
must  be  examined. 

Initiatives  that  will  help  define  the  career 
expectations  for  the  individual  officer  and  en¬ 
listed  member  are: 

*  Information  Systems  Ratings.  RM  2000  is  the 
first  step  towards  changing  not  only  the  way  we 
look  at  Radiomen,  but  the  way  in  which  we  view 
all  SEW  ratings.  Itinterjects  into  the  usual  rating 
review  process  additional  guidance  based  on  the 
technical  requirements  of  SEW.  Instead  of  re¬ 
viewing  RMs  ’  occupational  standards  by  assess¬ 
ing  present  tasking  (which  is  mostly  clerical  in 
nature),  the  focus  is  on  the  data  processing  and 
maintenance  functions  they  will  perform  by  the 
year  2000.  By  developing  these  standards  now, 
Navy  will  be  able  to  start  creating  the  operators 
and  maintainers  needed  in  the  future.  Concur¬ 
rently,  a  similar  data  processing  (DP)  rating 
review  is  being  conducted.  The  results  of  these 
projects  will  determine  whether  these  two  rat¬ 
ings  should  be  merged  into  one  Information 
Systems  rating; 
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•  The  SEW  Officer.  We  need  to  develop  officers 
who  are  trained  and  educated  throughout  their 
careers  with  emphasis  on  SEW.  By  increasing 
promotion  opportunities,  briefing  screening 
boards  about  SEW,  recruiting  interested  junior 
officers  and  accessions,  and  providing  a  viable 
career  path  we  can  retain  the  expertise  needed  to 
support  the  SEW  WMA;  and 

•  General  Unrestricted  Line.  A  Process  Action 
Team  has  been  initiated  to  ensure  that  General 
Unrestricted  Line  SEW  officers  are  able  to  ad¬ 
vance  and  develop  within  their  subspecialty  com¬ 
munity.  By  providing  a  career  path  with  proven 
leadership  and  subspecialty  tours,  the  Navy  will 
be  able  to  grow  and  retain  expertise  in  this 
essential  area.  This  career  path  would  parallel 
that  of  the  SEW  Officer’s. 

The  key  to  obtaining  individuals  with  the 
knowledge  and  skills  essential  for  the  technol¬ 
ogy  of  tomorrow  is  to  plan  for  their  training  now. 
Increased  automation  and  commonality  of  nodes 
implies  both  a  need  to  train  fewer  people  and  to 
streamline  the  training  for  those  who  are  still 
required;  yet,  the  technical  nature  of  these  sys¬ 
tems  indicates  that  more  in-depth,  advanced 
training  will  be  needed  than  now  exists.  The 
long-term  training  Investment  Strategy  should 
result  in  no-net  growth.  To  accommodate  this 
strategy,  curricula,  trainingpipelines,  and  schools 
must  be  examined  with  an  eye  to  the  future. 
With  each  system  acquisition,  the  following 
training  issues  should  be  considered: 

•  Technology.  A  system  must  be  fully  supported 
by  training  throughout  its  life  cycle  and  future 
generations.  By  calculating  the  cost  up  front, 
system  integrity  and  function  are  enhanced. 
Embedded  courseware  and  onboard  training  is 
one  of  the  most  promising  training  vehicles  for 
the  future.  Not  only  will  such  training  reduce 
instructor  man-hours,  it  could  also  potentially 
reduce  refresher  training  and  on-the-job  training 
(OJT)  needed  to  keep  personnel  fully  capable. 
In  addition  to  embedded  and  onboard  training, 
multimedia  avenues  such  as  video  training  should 


be  explored.  By  having  the  training  readily 
available  at  the  command,  personnel  can  be 
trained  while  on  the  job  vice  attending  a  school; 

Training  Economies.  By  viewing  training  re¬ 
quirements  as  a  whole,  we  can  begin  to  identify 
where  individual  reductions  can  be  taken.  Since 
many  of  the  systems  share  a  commonality  of 
nodes,  we  should  be  able  to  eliminate  or  stream¬ 
line  a  large  portion  of  training  as  it  exists  today. 
Likewise,  redundant,  outmoded,  or  underused 
training  should  be  eliminated.  If  embedded 
training  or  OJT  can  replace  a  particular  curricu¬ 
lum,  our  investment  strategy  should  incorporate 
these  changes.  Cost  efficiency  through  use  of 
existing  interservice  training  should  be  investi¬ 
gated  whenever  feasible.  Training  needs  to  be 
continuously  reviewed  to  ensure  that  it  supports 
standardized  fleet  operating  and  maintenance 
procedures.  By  developing  curricula  in  modular 
formats,  course  length  and  content  can  easily  be 
adjusted  to  meet  existing  needs.  Emphasis  should 
be  placed  on  overarching  systems  training,  using 
systems  technical  manuals,  to  provide  general 
knowledge,  which  can  be  transferred  from  job  to 
job  or  equipment  to  equipment  Specific  training 
initiatives  that  incorporate  these  aspects  include: 

-  SEW  Training  Continuum/Naw  Training 
Annraisal.  Copernicus  systems  and  require¬ 
ments  will  be  driving  these  Navy-wide  nam¬ 
ing  efforts.  Exposing  other  platform  and 
resource  sponsors  and  major  fleet  commands 
to  this  concept  will  assist  in  gaining  wide 
acceptance  and  further  input  into  training/ 
manpower  decisions; 

-  Process  Action  Teams/OualitvManagement 
Boards.  The  SEW  Training  QMB  has  sev¬ 
eral  PATs  planned  or  in  process  to  examine 
curricula  or  course  content  Schools  such  as 
Communications  Officer  Ashore/Afloat  will 
be  evaluated  to  determine  whether  they  ad¬ 
dress  the  Navy’s  current  operational  needs 
on  a  cost  effective  basis.  Future  efforts  need 
to  embrace  a  total  SEW  enlisted  ratings 
review  to  determine  manpower  and  training 
requirements; 

•  Reserve  Training.  As  demonstrated  by 
events  in  the  Persian  Gulf,  Naval  Reserve 
personnel  will  continue  to  play  an  important 
role  in  the  Total  Force  structure.  Their 
readiness  is  directly  affected  by  the  quality 
and  availability  of  training.  Each  system 
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within  the  Copernicus  Architecture  must  be 
assessed  in  terms  of  manpower  require¬ 
ments.  If  a  system  would  be  used  by  mobi¬ 
lized  forces,  its  associated  schools  and 
courses  should  be  revised  to  a  modular  con¬ 
cept; 

-  RM.  DP  Schools  Update.  The  “A”  and  “C” 
schools  for  both  ratings  are  being  updated  to 
incorporate  actual  or  anticipated  techno¬ 
logical  advances.  Course  structure  is  being 
modularized  in  anticipation  of  futurechanges 
as  new  equipment  is  introduced  to  the  fleet 
To  further  this  effort,  a  training  analysis 
should  be  performed  to  consider  the  follow¬ 
ing:  1)  When  should  the  training  come  on 
line?  2)  Will  it  require  additional  resources 
(instructors.TechnicalTrainingEquipment, 
contractors)?  3)  What  will  the  student 
throughput  be?  4)  How  many  modules  need 
to  be  rewritten?  As  mentioned  earlier,  in¬ 
creased  automation  will  mean  a  decrease  in 
manpower.  However,  “A”  and  “C”  schools 
need  to  be  equipped  to  teach  at  a  higher, 
more  technical  level  to  match  the  complex¬ 
ity  of  the  equipment  involved;  and 

-  Total  Quality  Leadership  rrOT.V  The  analy¬ 
sis  tools  and  thought  processes  involved  in 
TQL  lend  itself  to  investment  strategy  appli¬ 
cations.  Implementing  TQL  methods  for 
manpower/training  issues,  such  as  curricula 
and  rating  structures  is  essential  to  both  the 
short  term  and  long  term  success  of  the 
Copernicus  Architecture. 


R&D  IMPLICATIONS 

The  objective  of  the  R&D  Investment 
Strategy  is  to  provide  guidance  on  planning  the 
most  cost-effective  implementation  of  needed 
Copernicus  and  SEW  improvements.  This  will 
be  accomplished  by  describing  the  goals  and 
visions  toward  which  we  are  striving,  discuss¬ 
ing  the  processes  needed  to  develop  and  execute 
the  path  to  those  goals,  and  providing  specifics 
that  will  direct  and  guide  the  processes.  The 


specifics  will  be  grouped  in  the  categories  of 
technologies,  management,  and  implementation. 

Systems  Engineering 

The  process  todefine  both  the  Copernicus 
Architecture  and  the  SEW  Architecture  falls 
both  within  the  framework  of  systems  engineer¬ 
ing  and  operations  analysis.  Systems  Engineer¬ 
ing  provides  the  tools  and  rationale  for  perform¬ 
ing  cost/performance  tradeoffs  to  minimize  life- 
cycle  costs  while  providing  an  acceptable  level 
of  capability.  The  size  of  the  universe  being 
considered  determines  the  outcome  of  the  sys¬ 
tem  engineering  process.  When  one  considers 
only  a  small  (system)  universe,  the  system 
trades  become  requirements-driven  since  there 
is  no  cost  penalty  for  optimizing  design.  How¬ 
ever,  when  one  considers  a  very  large  universe, 
such  as  C4I  or  up  the  hierarchy  to  SEW  itself,  the 
system  trades  become  standards-  and 
interoperability-driven  because  of  the  enormous 
cost  savings  realizable  from  commonality. 

Technologies 

Technologies  can  be  viewed  as  func¬ 
tional  areas  (e.g.,  signature  control,  data  fusion) 
definable  within  all  categories  of  R&D2.  Tech¬ 
nology  is  not  a  “show  stopper”  to  achieving  the 
Copernicus  Architecture.  Identifying  and  ap- 

2 

R&D  categories  are:  6.1  (Research),  6.2  (Exploratory  Devel¬ 
opment),  63  (Advanced  Development),  6.4  (Engineering  De¬ 
velopment),  6.5  (Management  and  Support),  6.6  (Operational 
System  Development). 
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plying  the  correct  technology  (a  function  of  the 
systems  engineering  process)  is,  however,  criti¬ 
cal.  Technologies  that  support  the  systems  engi¬ 
neering  process,  such  as  analysis,  simulation 
and  modeling,  will  be  given  high  priority.  Engi¬ 
neering  development  efforts  will  be  directed 
toward  fixing  critical  operational  deficiencies, 
building  the  Copernicus  communications  “back¬ 
bone”  (e.g.,  CSS,  BITS,  Long  Haul  Architec¬ 
ture,  Navigation  Satellite  Timing  and  Ranging 
Global  Positioning  System  [NAVSTAR  GPS]), 
and  transitioning  lingering  existing  systems  (i.e., 
non-Copemican  systems  that  will  be  available 
for  a  long  time  because  of  sunk  costs,  momen¬ 
tum,  complexity,  or  cost  to  replace)  to  the  Co¬ 
pernicus  Architecture. 

Looking  to  the  future  to  determine  what 
it  will  take  to  achieve  the  SEW  Architecture, 
certain  technologies  are  critical  and  will  require 
advances  to  achieve  desired  architectural 
performance.  These  technologies  include 
networking  and  network  management,  data 
fusion,  signature  control,  distributed  operating 
systems,  and  data  compression.  In  addition  to 
these  technologies,  initiatives  in  antennas, 
software  producibility,  simulation  and  modeling, 
AI/Expert  systems,  integrated  optics,  detection/ 
recognition,  two-way  communications  with 
submarines,  and  decision  support  should  also  be 
supported. 


Management 

In  the  area  of  R&D  management,  two 
initiatives  should  be  pursued.  A  systems  engi¬ 
neering  consortium  should  be  established.  The 
consortium  would  develop  recommended 
changes  in  the  acquisition  process  to  accommo¬ 
date  rapidly  changing  technology  and  work 
closely  with  OP-094  in  obtaining  approval  from 
OP-9 1  or  the  Secretary  of  the  Navy,  as  appropri¬ 
ate. 

As  exploratory  development  needs  are 
identified,  the  Office  of  Naval  Technology  (ONT) 
should  work  closely  with  OP-094  to  incorporate 
these  needs  within  the  ONT  plans  and  to  define 
transition  strategies  for  inserting  the  exploratory 
development  results  into  the  SEW  effort. 

Implementation 

RDT&E  funds  will  be  limited,  and  only 
the  highest  priority  needs  can  be  expected  to  be 
supported.  Implementation  will  have  to  be  or¬ 
derly  and  timely  so  that  no  artificial  roadblocks 
are  created.  (See  chap.  10). 

Additionally,  certain  specific  areas  in 
Copernicus  clearly  need  definition  and  additional 
work.  These  include  network  requirements  and 
distributed  fusion.  Network  requirements  must 
be  defined  in  order  for  system  interfaces  can  be 
understood.  Distributed  fusion  is  an  essential 
element  to  allow  the  transformation  of  data  into 
information.  It  is  an  extremely  difficult 
technology  area  and  has  not  yet  been  addressed 
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in  sufficient  detail  within  Phase  I  of  the 
architectural  effort 


R&D  Game  Plan 

The  “game  plan”  for  Copernicus  R&D 
will  be  as  follows,  (1)  use  existing  programs  for 


R&D  focal  points  as  appropriate,  (2)  make 
maximum  utilization  of  commercial  R&D,  (3) 
use  DOD  and  other  Government  R&D  efforts 
where  useful,  and  (4)  use  Navy  R&D  to  fill  the 
gaps  and  aid  in  transition  of  enduring  systems  to 
Copernicus  Architecture. 


ANNEX A 

PROGRAMMATIC  REQUIREMENTS 


The  following  requirements  are  related  to  programmatic  implementation  of  the  Copernicus 
Architecture. 

9-PR-l:  Review  and  Devolve  Existing  Programs.  There  is  a  requirement  to  conduct  a  review  and 
devolve  all  existing  OP-094  C4I-related  programs  to  determine  and  describe  potential  Copernicus 
building  blocks  currently  in  development 

9-PR-2:  Describe  Pillars  as  Engineering  Models.  There  is  a  requirement  to  describe  the  Copemican 
pillars  as  functional  engineering  models  based  on  guidance  contained  in  Chapter  8. 

9-PR-3:  Develop,  Publish,  Use  Engineering  Criteria  for  Engineering  Models.  There  is  arequirement 
to  develop,  publish  and  use  engineering  criteria  including  affordability,  feasibility,  and  suitability  for  the 
component  derived  from  9-PR-l. 

9-PR-4:  Conduct  Engineering  Analysis.  There  is  a  requirement  to  conduct  an  engineering  analysis 
to  determine  “best  of  breed”  of  existing  building  blocks  derived  from  the  above  analysis. 

9-PR-5:  Define  Component  ILS  Strategies.  There  is  arequirement  to  define  component  ILS  strategies, 
including  technology  refreshment  through  the  PIM  concept  where  appropriate,  for  Copemican  building 
blocks  derived  from  the  process  above. 

9-PR-6:  Develop  System- Wide  ILS  Strategies.  There  is  a  requirement  to  develop  system-wide  ILS 
strategies  within  the  pillars  of  the  Architecture. 

9-OR-l:  Establish  Copernicus  Architect.  There  is  a  requirement  to  establish,  as  a  focal  point  for  the 
effort  and  for  all  subsystems  and  components,  a  Copernicus  “Architect”  within  OP-094  who  will  ensure 
operational  and  architectural  continuity. 

9-OR-2:  Establish  Copernicus  Engineer.  There  is  a  requirement  to  establish,  as  a  focal  point  for 
systems  engineering,  a  Copernicus  “Engineer”  within  SPAWAR  who  will  ensure  engineering  continu¬ 
ity. 

9-OR-3:  Establish  Copernicus  Programmer.  There  is  a  requirement  to  establish,  as  a  focal  point  for 
programmatic  implementation,  a  Copernicus  Programmer  within  OP-094  who  will  migrate  existing 
programs  across  the  program  directorates  into  the  Copemican  mold. 
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CHAPTER  10 

IMPLEMENTATION  STRATEGY 


SUMMARY 

Phase  II  will  consist  of  three  main  thrusts: 

•  The  establishment  on  the  OP-094  staff  of  a  Space  and  Electronic  Warfare  (SEW)  Architect  delegated  broad 
architectural,  managerial  ,  and  operational  authority  over  the  development  of  the  SEW  Systems*  including  the 
Copernicus  Architecture. 

•  The  establishment  on  the  Space  and  Naval  Warfare  Systems  Command  (COMSPAWARSYSCOM)  staff  of  a 
SEW  Engineer,  delegated  systems  integration  and  engineering  oversight  of  the  SEW  systems,  including  the 
Copernicus  Architecture. 

•  The  establishment  on  the  OP-094  staff  of  a  SEW  Programmer,  delegated  responsibility  for  programmatic 
integration  of  SEW  systems;  including  the  Copernicus  Architecture. 

The  SEW  Architect  will  be  established  as  a  staff  element  independent  of  existing  division  directors.  His 
responsibilities  include  architectural  and  operational  oversight  of  all  OP-094-sponsored  programs,  existing  and  future,  to 
ensure  all  compliance  with  Copernicus  standards  arid  applicability  within  the  architecture. 

During  Phase  n  efforts,  the  Architect  will  focus  on  two  broad  areas:  the  establishment  of working  groupscomposed 
of  fleet,  claimancy ,  and  industry  personnel  to  produce  individual  operational  requirements  (OR)  and  concepts  of  operations 
(CONOP)forthefourpillarsandexpanding  the  level  of  detail  on  the  Architectnreacross  Navy  Department  disciplines  (e.g., 
SSN,  Marine  Air  Ground  Task  Force  [MAGTF],  Special  Operating  Forces)  and,  if  directed,  up  and  across  echelons  into 
a  joint  model. 

The  SEW  Engineer  will  be  established  in  COMSPAWARSYSCOM.  His  responsibilities  include  Copernicus 
systems  engineering,  development  of  engineering  models,  “best  of  breed”  building  block  selection,  rapid  prototyping 
efforts.  Common  Operating  Environment  (COE)  definition,  and  general  technical  support  for  the  SEW  Architect. 

During  Phase  n  efforts,  the  Engineer  will  focus  on  four  tasks: 

•  The  development  of  a  functional  description  document  for  each  of  the  pillars; 

•  The  development  of  an  end-to-end,  integrated,  engineering  model  of  the  pillars; 

•  From  that  model,  a  “best  of  breed”  building  block  selection  recommendation  to  the  Architect;  and 

•  The  expansion  of  fleet  architectural  and  monitoring  efforts  (OTH-T)  into  SEW  field  engineering  support. 

The  SEW  Programmer  will  be  established  within  the  current  programming  division  of  OP-094.  This  office  will 
effect  the  transition  to  Copernicus  programmatically  (versus  from  an  engineering  standpoint)  from  stove  pipe  programs  of 
today  to  three  basic  types  in  the  future:  1)  building  block  programs,  2)  pillar  programs,  and  3)  research,  development,  test, 
and  evaluation  (RDT&E)  programs. 

DISCUSSION 


In  the  preceding  nine  chapters,  we  dis¬ 
cussed  the  requirements  derived  from  Phase  I 


(October  1990  to  July  1991)  working  groups 
that  are  needed  to  implement  the  Copernicus 
Architecture.  In  this  chapter,  we  describe  the 
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implementation  strategy  for  Phase  II  (ending 
Jan.  93)  of  the  effort. 

Phase  II  will  consist  of  three,  and  possi¬ 
bly  four  (i.e.,  joint  model),  main  thrusts  (see  fig. 
10-1): 

•  The  establishment  on  the  OP-094  staff  of  a  Space 
andElectronic  Warfare  Architect  delegaledbroad 
architectural,  managerial,  and  operational  au¬ 
thority  over  the  development  of  the  SEW  Sys¬ 
tem,  including  the  Copernicus  Architecture; 

•  The  establishment  on  the  COMSPAWAR- 
SYSCOM  staff  of  a  SEW  Engineer,  delegated 
systems  integration  and  engineering  oversightof 
the  SEW  System,  including  the  Copernicus  Ar¬ 
chitecture;  and 

•  The  establishment  on  die  OP-094  staff  of  a  SEW 
Programmer,  delegated  responsibility  for  pro¬ 
grammatic  integration  of  SEW  systems,  includ¬ 
ing  the  Copernicus  Architecture. 


Although  each  office  will  have  responsi¬ 
bilities  for  all  SEW  systems,  this  document 
focuses  on  the  Copernicus  Architecture.  For  the 
remainder  of  the  discussion,  the  responsibilities 
of  the  three  positions  above  will  center  on  that 
SEW  subsystem. 

SEW  ARCHITECT 

The  SEW  Architect  will  be  established 
as  a  staff  element  independent  of  existing  divi¬ 
sion  directors.  His  responsibilities  include  ar¬ 
chitectural  and  operational  oversight  of  all  OP- 
094-sponsored  programs,  existing  and  future,  to 
ensure  compliance  with  Copernicus  standards 
and  applicability  within  the  architecture. 


PHASE  i 
;  {Oct  90 -July  91) 


PHASE  II 
(July  91  -  July  93) 


Copernicus 

Architect 

Established 

(OPNAV) 


OPERATIONS  TEAMS 
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Engineer 

Established 

/cvcrAi  /v 
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Figure  10-1.  Phase  D  Copernicus  Efforts 
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During  Phase  II  efforts,  the  Architect 
will  focus  on  two  broad  areas:  the  establishment 
of  woridng  groups  composed  of  fleet,  claimancy 
and  industry  working  groups  to  produce  indi¬ 
vidual  operational  requirements  and  concepts  of 
operations  for  the  four  pillars  and  expanding  the 
level  of  detail  in  the  architecture  across  Navy 
Department  disciplines  (e.g.,  SSN,  MAGTF, 
SOF)  and,  if  directed,  up  and  across  echelons 
into  a  joint  model. 

Additionally,  the  Architect  will  ensure 
alignment  of  the  architecture  with  Department 
of  Defense  plans  for  implementing  Corporate 
Information  Management  (CIM)  by  blending 
management  information  systems  ashore  with 
tactical  C4I  systems  afloat 

Methodology 

To  affect  a  more  complete  definition  of 
the  Global  Information  Exchange  System 
(GLOB DCS)  structures,  the  Architect  will  estab¬ 
lish  a  series  of  simultaneously  convened  work¬ 
ing  groups  to  be  headed  by  the  designated  claim¬ 
ant  for  each  GLOBBCS.  Figure  10-2  shows 
claimancies  by  GLOBDCS.  Each  GLOBBCS 
working  group  will  be  co-chaired  by  a  designee 
from  the  Architect  staff  and  from  the  claimant 
and  will  be  tasked  to  produce  an  operational 
requirement  (OR)  and  a  CONOP  that  establishes 
GLOBDCS  subscribership,  information  services, 
and  operations. 

Three  working  groups  will  be  convened 
for  the  Tactical  Information  Exchange  Systems 


(TADDCS):  one  each  forthe  CarrierBattle  Group 
(CVBG),  SSN,  and  Marine  Corps  communities. 
Each  will  be  tasked  to  produce  a  CONOP. 

The  Commander  in  Chief  (CINC)  Com¬ 
mand  Complex  (CCC)  and  Tactical  Command 
Center  (TCC)  pillars  will  be  developed  by  the 
existing  Fleet  Project  Team  (FPT)  and  Fleet 
Requirements  Working  Group  (FRWG)  respec¬ 
tively.  Additionally,  each  Fleet  CINC 
(FLTCINC)  will  be  requested  to  submit  require¬ 
ments  for  the  construction  of  their  respective 
CCCs.  The  output  of  these  efforts  will  be  a 
Program  Change  Approval  Document  (PC AD) 
to  the  Operation  Support  System  (OSS)  and 
Tactical  Flag  Command  Center  (TFCC)  ORs. 
See  figure  10-3. 

SEW  ENGINEER 

The  SEW  Engineer  will  be  established  in 
COMSPAWARSYSCOM.  His  responsibilities 
include  Copernicus  systems  engineering,  devel¬ 
opment  of  engineering  models,  “best  of  breed” 
building  block  selection,  rapid  prototyping  ef¬ 
forts,  COE  definition,  and  general  technical  sup¬ 
port  for  the  SEW  Architect 

During  Phase  II  efforts,  the  Engineer 
will  focus  on  four  tasks,  shown  in  figure  10-4: 

•  The  development  of  a  functional  description 
document  for  each  of  the  pillars; 

•  The  development  of  an  end-to-end,  integrated, 
engineering  model  of  the  pillars,  based  on  a 
defined  set  of  Copernicus  building  blocks.  Defi¬ 
nition  of  the  Copernicus  building  blocks  will  be 
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Figure  10-2.  Proposed  GLOBIXS  Responsibilities 
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Figure  10*3.  SEW  Architect  Phase  n  Efforts 
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Figure  10-4.  SEW  Engineer  Phase  H  Efforts 


accomplished  in  terms  of  the  Common  Operat¬ 
ing  Environment  (COE)  previously  described  in 
chapter  8; 

•  From  that  model,  a  “best  of  breed”  building 
block  selection;  and 

•  The  expansion  of  fleet  architectural  and  moni¬ 
toring  efforts  (OTH-T)  into  SEW  field  engineer¬ 
ing  support 


<<Best  of  Breed”  Selection 

As  we  saw  in  the  preceding  chapter, 
selection  of  “best  of  breed”  building  blocks  will 
allow  broad  standardization  throughout  the  ar¬ 
chitecture  and  make  possible  more  affordable, 
tailored  Integrated  Logistics  Support  (ILS)  strat¬ 
egies. 


Figure  10-5  illustrates  the  anticipated 
“best  of  breed”  process.  Existing  stove  pipe 
programs  will  be  mapped  to  pillars  (e.g.,  pro¬ 
grams  A,  B,  and  C  in  the  figure)  The  programs 
will  be  devolved  into  like  building  blocks  and 
compared  for  feasibility,  suitability  and 
affordability.  In  the  figure,  blocks  A2,  B3,  and 
Cl  represent  all  existing  building  blocks  of  a 
single  family  (e.g.,  communications  processor, 
storage  device,  modem,  terminal).  From  the 
family  of  three,  one  “species”  —  B3 —  is  se¬ 
lected  as  “best  of  breed.” 

B3 ,  however,  may  fall  short  of  the  desired 
Copemican  building  block  E  defined  in  the 
engineeringmodels.  Transition  engineering  will 
provide  for  improvement  of  B3  through  either  of 
two  means.  First,  B3  may  be  improved. 
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"Stowe  Pipe"  ftogmn*  A,  B,feC  • 


Figure  10-5.  Stove  Pipe  Programs  to 
Building  Block  Programs 


producing  B31.  Alternatively,  the  suitability, 
affordability,  or  feasibility  of  B3  may  mean 
using  B3  as  an  interim  block  even  though  it  is  far 
from  the  desired  capability.  In  this  latter  case, 
rapidprototyping  to  achieve  blockD  might  be  an 
attractive  option  to  lead  to  E. 

These  engineering  considerations 
necessarily  will  determine  the  length  of  time. 
between  today ’s  architecture  and  the  Copernicus 
Architecture  and  must  be  defined  before  actual 
implementation  time  can  be  estimated  accurately. 
Once  they  are,  it  will  be  possible  to  map  additional 
transitional  phases —  beyond  definition  and 
planning  of  Phase  II  to  follow  on  operations  and 
programmatic  phases —  over  the  next  decade  in 
which  to  implement  the  architecture. 


SEW  PROGRAMMER 

The  SEW  Programmer  will  be 
established  within  the  current  programming 
directorate  of  OP-094.  This  office  will  effect  the 
transition  programmatically  (versus  from  an 
engineering  standpoint)  from  stove  pipe 
programs  of  today  to  three  basic  types  in  the 
future:  1)  building  block  programs,  2)  pillar 
programs,  and  3)  RDT&E  programs. 

Building  block  programs  exist  today, 
but  not  across  the  board.  Instead,  we  have  a 
combination  of  building  block  programs  (e.g., 
KG-84)  and  “stove  pipe”  programs  (e.g..  High 
Speed  Fleet  Broadcast,  Officer  in  Tactical 
Command  Information  Exchange  System,  Ocean 
Surveillance  Information  System,  Baseline 
Upgrade).  The  result  is,  we  have  several 
programs  working  toward  the  same  functional 
building  block,  but  producing  different  versions 
of  it  (and  using  different  funding  lines).  In  the 
future,  we  plan  to  pull  building  blocks  from  the 
stove  pipe  programs  to  build  Copernicus  block 
programs,  based  on  the  ORs  derived  from  the 
Architect  teams  and  the  models  and  "best  of 
breed"  recommendations  of  the  Engineer. 

Pillar  programs  will  reflect  the  funding 
lines  necessary  to  build  and  operate  the  individual 
GLOBIXS,  CCCs,  and  TCCs.  Funding  will 
have  to  be  provided  for  leased  bearer  services  to 
provide  software  and  maintenance  support  and 
to  construct  (where  necessary)  the  nodes  and 
centers  that  make  up  the  pillars.  Although  the 
engineering  basis  for  an  imagery  GLOBIXS 
might  be  the  same  for  Research  andDevelopment 
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Information  Exchange  System  (RDIXS),  clearly  defined  shortfalls.  Figure  10-6  shows  the 

locations,  subscribership,  existing  connectivity,  SEW  Programmer's  Phase  II  efforts, 

andotherrequirements  will  drive  different  budget 
requirements.  Pillar  programs  will  allow  the 

claimant  to  operate  the  pillar.  SEQUENCE  OF  TASKS 


Finally,  RDT&E  programs  today  are 
generally  reflective  of  stove  pipe  efforts.  The 
great  advantage  of  an  architecture  is  that  it 
makes  RDT&E  shortfalls  obvious.  Today,  to 
pick  three  examples,  we  have  critical 
requirements  for  data  compression,  affordable 
ultra  high  frequency  (UHF)  multiplexing,  and 
data  file  transmission  to  sea.  Other  examples 
abound:  lower  bit-rate  voice,  voice/data 
interleaving,  electronically  tunable  antennas,  and 
so  on.  RDT&E  programs  in  the  future  will  be 
tied  to  functional  goals  and  be  executed  to  solve 


Figure  10-7  shows  all  three  efforts  in 
sequence.  The  engineering  work  will  begin  with 
the  development  of  the  Functional  Description 
Documents  (FDDs).  These  will  be  used  to 
provide  the  engineering  basis  for  the  architectural 
work  in  the  pillar  teams  to  develop  ORs  and 
CONOPs,  which  will  occur  simultaneously. 
Following  development  of  the  FDDs,  the 
Engineer  will  turn  to  development  of  pillar 
engineering  models  and  conduct  his  “best  of 
breed”  analysis.  From  the  CONOPs  of  the 
pillars,  the  Program  Office  will  establish  pillar 


SEW  PROGRAMMER  OP-940 

POM- 

94,96,98 

GLOBIXS 

CCC* 

TADIXS 

TCC* 

♦Efforts  expected  to  be  concurrent  and  yield  similar  blocks. 

Figure  10-6.  SEW  Programmer  Phase  II  Efforts 
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programs  for  the  CCCs,  the  TCCs,  and  the 
GLOBIXS.  Similarly,  from  the  “best  of  breed” 


analysis,  the  Programmer  will  develop  building 
block  programs  from  the  existing  stove  pipes. 


ANNEXA 

IMPLEMENTATION  REQUIREMENTS 


10-IR-l:  Adminstrative  Support  for  the  Architectect  and  Programmer..  There  is  a  requirement  to 
provide  administrative  support  for  the  Architect  and  Programmer  during  Phase  II. 

10-IR-2:  Operational  Requirement  and  Concept  of  Operations  for  GLOBIXS.  There  is  a 
requirement  to  develop  an  operational  requirement  and  an  concept  of  operations  for  all  GLOBIXS. 

10-IR-3:  Concept  ofOperationsforTADIXSinSSN,USMC,SOF.  There  is  arequirement  to  develop 
a  concept  of  operations  for  TADIXS  for  the  SSN,  Marine,  and  Special  Operating  Force  Communities. 

10-IR-4:  Program  Change  Approval  Document  for  OSS  and  TFCC.  There  is  a  requirement  to 
develop  a  program  change  approval  document  for  the  OS  S  and  TFCC  programs  to  reflect  the  Copemican 
requirements  for  CCC  and  TCC,  respectively. 

10-TR-l:  Functional  Description  for  Pillars.  There  is  a  requirement  to  develop  a  functional 
description  document  for  each  pillar. 

10-TR-2:  Engineering  Model  for  Pillars.  There  is  a  requirement  to  develop  an  engineering  model  for 
each  pillar  based  on  a  defined  set  of  Copernicus  building  blocks.  Definition  of  the  Copernicus  building 
blocks  will  be  accomplished  in  terms  of  the  Commmon  Operating  Environment  (COE). 

10-TR-3:  Best  of  Breed  Analysis  for  Pillar  Building  Blocks.  There  is  a  requirement  to  conduct  a  “best 
of  breed”  analysis  for  the  pillar  building  blocks  and  make  recommendations  for  those  building  blocks 
to  the  Architect. 

10-TR-4:  Identify  Missing  Building  Blocks.  There  is  arequirement  to  identify  missing  building  blocks 
and  make  recommendations  to  the  Architect 

10-PR-l:  Develop  Pillar  Programs  for  GLOBIXS,  CCC,  TCC.  There  is  a  requirement  to  develop 
pillar  programs  to  implement  the  GLOBIXS,  the  CCC,  and  the  TCCs. 

10-PR-2:  Develop  Building  Block  Programs.  There  is  a  requirement  to  develop  building  block 
programs  based  on  the  “best  of  breed”  selection  process. 

10-PR-3:  Develop  RDT&E  Programs  for  Building  Blocks.  There  is  a  requirement  to  develop 
RDT&E  or  other  appropriate  programs  for  building  blocks  required  by  the  architecture  but  not  currently 
in  being. 
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The  Copernicus  Architecture 

Technology  Team 
OUTBRIEF 


—  Technology  Team 


Technical  Team  Findings 


•  Copernicus  concept  judged  technologically  sound! 

•  GLOBIXS  are  virtual  (vice  physical)  nets 

-  GLOBIXS  will  be  operated  on  DCS  backbone 

-  DDN  and  DCTN  plus  available  commercial 

•  DDN  time  will  be  significant  cost  to  subscribers 

•  GLOBIXS/TADIXS  media: 

-  Text,  voice,  data  files,  imagery  and  video 

-  Expense/subscriber  drives  media  mix  among  nodes 

-  Full  motion  video/studios  are  unnecessary 

•  Some  GLOBIXS  require  little  to  implement 

•  Navy  implementation  will  be  OSI  and  GOSIP  standards 

-  GLOBIXS  will  be  100%  GOSIP  (possible  one  exception) 

-  Objective  for  TADIXS  (EMCON/ Protocol  overhead  I) 

-  Message  service  implementation  will  be  DMS 

=  Navy's  C*I  Post  Cold  War  Architecture:  OP-094  .  . - 
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Technology  Team 


Technical  Team  Findings 


•  Four  basic  computer  building  blocks 

-  A  desktop  series 

-  A  tactical  workstation  series 

-  Communication  servers 

-  File  servers 

•  "PIM"  block  intervals  <6  but  >4  years 

-  Prime  mover  to  maintain  industry  competition 

•  Do  not  constrain  file/COMM/message  servers  to  DTC-2 

-  DTC-2  can  be  interface  device 

-  CCC  file  server  functions  were  described 

-  Separate  file  servers  for  encyclopedic/ track  data 
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Technical  Team  Findings 


•  Evolve  a  commonly  structured  Copernicus  tactical 
software  (e.g.  spreadsheet  application)  tailored  to  many 
warfare  areas 

-  Truncate  the  training  pipeline 

-  Junior  personnel  are  generic  terminal  operators 
specializing  later  in  their  careers 

•  The  concept  of  COTS/GOTS  is  good  but  more  rapid 
movement  in  that  direction  is  required 


•  A  veneer  software  is  required 

-  Fast  standardization  with  industry  hooks 

-  Flexibility  enough  for  unique  industry  interface 

•  Functional  description  of  FASTT  produced 


•  Accomplish  transliteration/ sanitization  as  close  to  the 
source  as  possible 

Navy's  C*I  Post  Cold  War  Architecture:  OP- 094 
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Technology  Team 


Technical  Team  Findings 


•  Functions  of  C2  center  processor  established 

•  Must  evolve  common  contact/ track  format  for  FASTTs 

•  Common  track  number  methodology  is  required 

•  MLS  is  not  mature  but  critical  to  full  implementation 

-  Will  greatly  streamline  architecture /data  flow 

-  Radiant  Mercury  endorsed  as  interim 
transliterator/sanitizer 


•  Common  message  format  desired 

-  Bit-oriented  preferred 

-  OPNOTES  in  BOM  BUT 

—  Some  text  messages  must  be  character-oriented 
—  Machine-machine  formats  desired 
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=  Technology  uam  i  Technical  Team  Findings 

•  Need  algorithms  for  GLOBIXS-TADIXS  sensors  plus  data 
fusion  strategy  for  cross-sensor  correlation  at  CCC/TCC 

•  Need  multiple  FOTC  doctrine  in  order  to  address 
enabling  technology  (trips  to  CDMCS  should  provide) 

•  Validated  need  of  dynamic  bandwidth  management 

-  CSS  is  viable  option  for  CCC>TADIXS>TCC  interface 
but  concerns  exist 
-  Early  commitment  to  VME 
—  MLS  certification  risk 
—  No  $  yet  spent  on  voice  integration 
—  Video  not  in  the  current  architecture 
—  Limited  work  evident  on  COMMS  mgt  functionality 
—  Potential  for  costly  retrofit  if  necessary 
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Technology  Team  see: . . .  Technical  Team  Findings 

•  Copernicus  architecture  will  implement  Navy  ITDN 

•  Need  joint  management  control  interface  for  military 
COMMS  equipment 

-  JTC3A  develop: 

—  Management  information  base  (MIB) 

—  Use  DDN  standard  protocol  (SNMP,  CMP) 

—  Applicable  to  CSS 

•  Interface  with  COMMS  PAT  for  loading  and  pipe  data 
characterization  for  technology  applications 
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Technology  Team  - - — ~  Technical  Team  R&D  Findings  = 

•  Low  rate  voice  (<2.4  KBS /desired  300  BPS) 

•  Distributed  DBMS 

•  Distributed  operating  systems 

•  Decision  support  tools 

•  Display  technology  to  include  large  screen  display 

•  AI  applications  for  COMMS  management 

•  Video-teleconferencing  at  32  KBS 

•  Multi-freq,  multi-aperture  SATCOM  antenna  to  include  commercial 
SATCOM  applications 

•  MUX  voice  plus  voice  on  virtual  circuit  (COMSEC) 

•  MUX  voice  with  data  on  virtual  circuit  (COMSEC) 

•  Investigate  fractal's  for  long  term  voice  and  video  applications 

•  Consider  MODS  to  NKDS  to  include  frequency  management 

Navy's  C*I  Post  Cold  War  Architecture:  OP-094 
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Technology  Team 


Summary 


•  Unique  government-industry  teamwork 

•  Expanded  awareness  and  acceptance  of  Copernicus  in 
the  industrial  and  development  communities 

•  Many  emerging  technologies  will  assist  implementation 
of  Copernicus  provided  COTS  and  GOTS  are  pushed 

•  Care  must  be  taken  not  to  accept  commercial  standard 
until  it  is  truly  adopted  industry  wide 

•  End  to  end  commercial  standards  where  applicable  could 
significantly  reduce  implementation  costs  as  well  as 
"PIM" 


The  Gopermcu*  Architecture 
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Communication  Team 
OUTBRIEF 


22  Communication  Temm 


Team  Goals 


•  Define  and  prioritize  communication  infrastructure  for  the 
Copernicus  Architecture 


-  What  kind  of  HF,  UHF  S  ATCOM,  SHF,  EHF,  and 
CommSAT? 

-  What  proportions  of  HF,  UHF  SATCOM,  SHF,  EHF,  and 
CommSAT? 

-  Where  in  the  architecture  do  we  use  each? 

-  What  are  our  priorities? 

-  When  should  we  invest  in  each? 


•  What  existing  programs  must  be  cancelled,  modified,  and/or 
accelerated  to  build  this  infrastructure? 
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Communication  Team 


Findings 


•  Delphi  analysis  of  transmission  media  completed,  comparing 
Copernicus  service  requirements  with  attributes  needed  for 
these  services. 


•  Detailed  analyses  summed  into  top  level  ranking  of 
transmission  media. 


•  Bottom  line:  UHF  SATCOM,  SHF  SATCOM,  and  modernized 
HF  have  greatest  potential  for  near-term  contribution. 

•  Affordability  may  constrain  extensive  HF  modernization. 
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Communication  Team 


Recommendations 


•  Re-evaluate  programs  during  Investment  Strategy  Team 
session.  Identify  the  Contribution  each  makes  toward  a 
Copemican  RF  capability. 
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22  Communication  Team  —-1131  .  A  Slice  through  the  Volume: 

Copernican  Record  Services 


HF 

UHF 

SATCOM 

SHF 

SATCOM 

Milstar 
Low  Data  Rata 

Milstar 
Madium 
Data  Rata 

EHF  on  UHF 
Follow-On 

Comma  rdai 
SATCOM 


Suitabla 


Good,  although  thara  is  no  anti-jam  capability 


Good,  although  anti-jam  data  rata  is  limHad  (as  low  as  75  bps) 


Good.  Currant  valid  at  ad  usas  oriantad  toward  tactical  massaga  exchanges. 
Accass  to  limHad  spaca  sagmant  is  a  problem. 


Applicabla  (futura  systam  now  baing  dasignad) 


Good.  Current  validated  usas  oriantad  toward  tactleaHraefc  messagr  exchanges. 
Accass  to  limHad  spaca  sagmant  is  a  problam. 


Good 


Covaraga  Throughput  Survivability  Growth  Oparation&  Limitations  Cost  Physical 

Maintananca  Charactariatlcs 
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communication  Team  =  A  Slice  through  the  Volume : 

Copernican  Data  Base  Exchange  Services 


HF 

UHF 

SATCOM 

SHF 

SATCOM 

Milstar 
Low  Data  Rata 

Milstar 

Madium 

Data  Rata 

EHF  on  UHF 
Follow-On 

Commarciai 

SATCOM 


auHabla,  dua  to  poor  airor  rata  of 


n^_  ^ ,  -  -  *  “ 


Good,  although  thara  is  no  anti-jam  capability 


Good,  aHhough  anti-jam  data  rata  is  limHad  (as  low  as  75  bps) 


Good.  Currant  validatad  usas  oriantad  toward  tactical  massaga  axchangas. 
Accass  to  limitad  spaca  sagmant  is  a  problam. 


Applicabla  (futura  systam  now  baing  dasignad) 


Good.  Currant  validatad  usas  oriantad  toward  tactical  track  massaga  axchangas. 
_ _ Accass  to  limHad  spaca  sagmant  is  a  problam. 


Good 


Covaraga  Throughput  Survivability  Growth  Opa ration  &  Limitations  Cost  Physical 

Maintananca  Characteristics 
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22  Communication  Team 


A  Slice  through  the  Volume:  -»— » 
Copernican  VoiceServices 


HF 

UHF 

SATCOM 

SHF 

SATCOM 

Milstar 
Low  Data  Rata 

Milstar 

Madium 

Data  Rata 

EHFon  UHF 
Follow-On 

Commarciai 

SATCOM 


Coverage  Throughput  Survivability  Growth  Operation  &  Limitation*  Coat  Physical 

Maintananca  Charact  an  atica 


Suitable,  but  not  optimum  dua  to  poor  arror  rata  of  madium _ _ 

Good,  although  thara  ia  no  anti-jam  capability 

in  some  extromajadjg^isctroniccombatsconariosMM^MMMM 

Good,  although  gatting  accaaa  to  tha  limited  apaoa  aagmant  ia  a  problem 
Applicable  (future  system  now  being  designed) 

Good,  although  gatting  access  to  the  limited  space  segment  is  a  problem 
Good 
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Copernican  Graphics  Data  Exchange 


HF 

UHF 

SATCOM 

SHF 

SATCOM 

Milstar 
Low  Data  Rate 


Milstar 
Medium 
Data  Rate 

EHF  on  UHF 
Follow-On 


Commercial 

SATCOM 


Coverage  Throughput  Survivability  Growth  Operation  &  Limitations  Cost  Physical 

Maintenance  Characteristics 


Suitable,  but  not  optimum  due  to  poor  error  rate  of  medium 
Good,  although  there  is  no  anti-jam  capability 


Good,  although  anti-jam  data  rate  is  limited  (as  low  as  75  bps) 


Good,  although  getting  access  to  tha  limited  space  segment  is  a  problem 


Applicable  (future  system  now  being  designed) 


Good,  although  gatting  access  to  the  limited  space  segment  is  a  problem 


Good 
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!£  Communication  Team  2522  .  A  Slice  through  the  Volume: 

Copernican  Facsimile  Services 


HF 

UHF 

SATCOM 

SHF 

SATCOM 

Milstar 
Low  Data  Rata 

Milstar 
Madium 
Data  Rata 

EHFon  UHF 
Follow-On 

Commercial 

SATCOM 


Suitable,  but  not  optimum  dua  to  poor  error  rate  of  medium 


Good,  although  there  la  no  anti-jam  capability 


Good,  although  anti-jam  data  rata  it  limited  (at  low  at  75  bpt) 


Good,  although  getting  acceee  to  the  limit  ad  apace  eegment  la  a  problem 


Applicable  (future  eyatem  now  being  detigned) 


Good,  although  getting  acceee  to  the  limited  space  segments  a  problem 


Good 


Coverage  Throughput  Survivability  Growth  Operation  &  Limitations  Cost  Physical 

Maintenance  Characteristics 
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Communication  Team  =  A  Slice  through  the  Volume:  . 

Copernican  Imagery  Transmission 


HF 

UHF 

SATCOM 

cup 

SATCOM 


Milstar 
Low  Data  Rate 


Milstar 

Medium 

Data  Rate 


EHF  on  UHF 
Follow-On 

Commercial 

SATCOM 


Coverage  Throughput  Survivability  Growth  Operation  &  Limitations  Cost  Physical 

Maintenance  Characteristics 


Navy’s  C4/  Post  Cold  War  Architecture:  OP-094 


Limited  due  to  current  32  kilobit  per  second  data  rate 


Applicable,  although  anti-jam  data  rate  it  limited  (aa  low  as  75  bps) 


Suitable,  although  2,400  bps  rate  is  not  optimum^ 


Applicable  (future  system  now  being  designed) 


Applicable,  but  high  band  width  satellites  may  not  cover  ocean  areas 
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A  Slice  through  the  Volume: 
Copernican  Video  Teleconferencing 


HF 

UHF 

SATCOM 

Limited  due  to  currant  32  kilobit  par  second  data  rata 

SHF 

SATCOM 

Applicable,  although  shore-ship-short  quality  may  not  be  good 

Milstar 
Low  Data  Rata 

MM 

Milstar 

Medium 

Data  Rata 

Applicable  (future  system  now  being  designed) 

EHFon  UHF 
Follow-On 

Commercial 

SATCOM 

Applicable,  but  high  band  width  satellites  may  net  cover  ocean  areas 

Coverage  Throughput  Survivability  Growth  O  pa  rati  or  &  Limitations  Coat  Physical 

Maintananca  Characteristics 
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(Continued) 

•  Establish  a  single  OP-094  point  of  contact  for  all  OP-094  architectural 
efforts. 


•  Analyze  backbone  architectures  in  comparison  to  Copernicus 
Architecture  requirements.  Other  architectures  affecting  OP-094 
programs  should  be  consolidated  into  Copernicus,  or  modified  to  be 
consistent  with  it. 


Current  Architecture  Paradigm 


Tactical 

Secure 

Radio 

Data 

Voice 

Frequency 

Link 

and 

Systems 

Data 

Systems 

Objective  Architecture  Paradigm 


Copernicus  Architecture 

SEW  System  Description 

Tactical 

Secure 

Radio 

Data 

Voice 

Frequency 

Link 

and 

Data 

Systems 

Systems 
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HI  Communication  Team 


Recommendations 

(Continued) 


•  CSS  should  be  used  to  implement  the  Copernicus  TADIXS  structure  afloat  and 
ashore. 


•  Investigate  political  and  legal  implications  of  using  Commercial  SATCOM  in 
CALOW  situations  that  do  not  involve  U.S.  operating  in  support  of  U.N. 
resolutions. 


•  Consider  how  to  invest  to  take  best  advantage  of  Commercial  SATCOM. 
Possible  alternative  approaches  may  include: 


-  Modular  antenna  systems. 

-  Integrated,  modular  SATCOM  terminals  that  can  plug-in,  plug-out 
capabilities  (both  military  and  commercial)  for  individual  missions  and 
Copemican  services. 


•  De-emphasize  Milstar  LDR  and  EHF  on  UHF  Follow  On  investment  when  it  is 
economical  to  do  so. 
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(Concluded) 

•  Minimize  investment  in  Milstar  Low  Data  Rate  (LDR). 

-  Procure  and  install  terminals  for  flagships  and  capital  ships. 

-  Go  slow  with  procurement  &  installation  for  smaller  ships  while  Milstar 
Medium  Data  Rate  (MDR)  clarifies. 

-  Participate  in  definition  of  Milstar  MDR. 

•  Use  UHF  Follow  On  EHF  capability,  but  don’t  invest  in  buying  more. 
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The  Copernicus  Architecture 

Copernicus! SEW 
Investment  Strategy 


Investment  Strategy  =  OBJECTIVES  ~ 

•  REFINE  COPERNICUS  INVESTMENT  STRATEGIES 

•  PROVIDE  FOCUS  FOR  POM-94 
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The  Copernicus  Architecture 


Investment  S  tra  tegy 


PHASES  OF  PANEL  WORK— 


REQUIREMENTS 


i 


CUT/FIX  UP 

INVEST  IN  FOLLOW-ON 
OH  NEW  START 
ASSOCIATE  PROGRAMS 
WITH  PILLARS 


!  I  I  TRANSITION  TRADEOFF?" 


SIZE  PROGRAMS  VS  COST 
REVALIDATE 

REQUIREMENTS  FOR- 
TIMING  AND  UTILITY 


PHASE  I 


PHASE  II 
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S  Investment  Strmtegy 


TOP-DOWN  ANALYSIS  = 


1 1. Allocate  programs  and  functions  to 
pillars 


I  2.  Analyze  functions  and  services 
required  to  make  the  pillar  real 


3.Analyze  utility  of  programs 
for  functions  and  services 


4.Make  recommendations: 

a.  Priority  Requirements 

b.  Restructure 

c.  Requires  Further 

Investigation _ 
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The  Copcnucui  Ardiitemn 


—  Investment  Strategy 


SEW  BASELINE 
ANALYSIS  STRUCTURE' 


The  Copenun*  Ardueeam 
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_  SEW  BASELINE  = 

Inrestmentstrategy  -  INVESTMENT  STRATEGY 

(BOTTOM-UP  APPROACH) 

•  PROGRAM  DATA  COLLECTED  AND  VERIFIED 

•  MODEL  LOADED  WITH  QUANTITATIVE  MEASURES 

-  CONFORMANCE  TO  COPERNICUS  DECISION 
POINTS 

-  CONTRIBUTION  TO  SEW  BASELINE 
REQUIREMENTS 

-  PROGRAMMATIC  HEALTHOF  PROGRAM 

-  28  DECISION  POINTS,  90  SPECIFIC  QUESTIONS 

•  LINKS  CURRENT  PROGRAM  REQUIREMENTS  TO 
COPERNICUS  BUILDING  BLOCKS 

•  WILL  BE  USED  TO  HELP  DERIVE  PROGRAM 
RANKINGS 
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SEW  BASELINE  _ , 

INVESTMENT  STRA  TEGY 
METHODOLOG  Y 


HEALTHY 


NUMERIC  SCORES 
FOR  DECISION  POINTS 


METHODOLOGY  REPRESENTED  AS  AN  EQUATION: 

SYSTEM  FIGURE  OF  MERIT  =  i(COPERNICUS)  +  J(SEW)  +  k(PROGRAMMATIC) 
Navy's  C*I  Post  Cold  War  Architecture:  OP-094 
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Investment  Strategy  SZIZmSZSSSSmiSmSSZZS  MANPO\A/ER  ,  PERSONNEL,  21 

AND  TRAINING 

•  MPT  INVESTMENT  ASSUMPTIONS: 

-  NO  NET-GROWTH  IN  MPN 

-  MODERNIZATION  SHOULD  REQUIRE  LESS 
MANPOWER 

-  TQL  APPROACH  TO  INVESTIGATE 
RESTRUCTURE  OF  ALL  SEW  ENLISTED 
RATINGS 

-  NO  NET-GROWTH  IN  TRAINING 

-  HUMAN /SYSTEM  INTEGRATION,  EMBEDDED 
AND  ONBD  TRAINING  =  LESS  EMPHASIS  ON 
SCHOOLHOUSE  TRAINING 

-  INCREASED  COMMONALITY  OF  NODES 
MEANS  GENERALIST,  SYSTEMS  INSTRUCTION 
APPROACH 
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=  Investment  Strategy  -  MANPOWER,  PERSONNEL,  = 

AND  TRAINING,  CONT'D 

•  FOUR  PRINCIPAL  FACTORS 

-  QUANTITY 

-  QUALITY 

-  TRAINING 

-  HUMAN/SYSTEMS  INTEGRATION 
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MANPOWER,  PERSONNEL,  = 
AND  TRAINING,  CONTD 


•  QUANTITY 


-  OVERALL  NAVY  DOWNSIZING 


-  SEW  MPN  DECREASED  SINCE  FY  90 


-  COPERNICUS  MPN  REQUIREMENTS  MUST  COME 
FROM  WITHIN  (NO  NET  GROWTH) 
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Investment  Strategy  =====  MANPOWER,  PERSONNEL,  = 

AND  TRAINING,  CONTD 

•  QUALITY 

-  TO  ENSURE  OUR  PEOPLE  HAVE  THE  "RIGHT  STUFF" 
FOR  COPERNICUS: 

-  SEW  CONTINUUM 

-  REVIEW  C4IENL  RATINGS  (TQL,QMB) 

-  IMPOSE  HIGHER  QUALIFICATIONS  FOR  C4I  ENLISTED/OFFICERS 

-  MODERNIZE  TRAINING  AND  PROVIDE  REFRESHER  TRAINING 

-  ONGOING  INITIATIVES  INCLUDE: 

-  RM  2000/DP  RATING  REVIEW 

-  SEW  OFFICER  PROFESSIONAL  DEVELOPMENT 

-  GEN  URL  SEW  PAT 

-  SEW  CENTER 

-  SEW  COMMANDER 

Navy's  C*I  Post  Cold  War  Architecture:  OP-094  . 
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=  Investment  Strategy . . .  MANPOWER,  PERSONNEL, 

AND  TRAINING,  CONT'D 

•  TRAINING-TO  MEET  ASSUMPTION  OF  NO  NET 
GROWTH,  STRATEGY  MUST  EMPHASIZE: 

-  TECHNOLOGY 

-  LIFE  CYCLE  TRAINING  COSTS 
~  EMBEDDED  COURSEWARE 

-  TRAINING  ECONOMICS 

-  SCHOOLHOUSE  AND  CURRICULUM  . 
CONSOLIDATION 

-  STREAMLINING  OF  PIPELINE  TRAINING 

-  EMPHASIS  ON  OVERARCHING  SYSTEMS 
TRAINING 
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=  Investment  Strategy  MANPOWER,  PERSONNEL  — 

AND  TRAINING,  CONT'D 

•  HUMAN/SYSTEM  INTEGRATION 

-  EMBEDDED  AND  ON-BOARD  TRAINING 

-  WILL  PROVIDE  REDUCED  TRAINING  COSTS 

-  BUILT-IN  TESTS  AND  USER-FRIENDLY  DIAGNOSTICS 

~  FASTER,  LESS  EXPENSIVE  MAINTENANCE 

-  GENERAL  SYSTEMS  INSTRUCTION 

-  COMMON  WORK  STATIONS 

-  WILL  PROVIDE  PERSONNEL  FLEXIBILITY 

-  SIMPLER  MAINTENANCE 

-  RECOGNIZING  BENEFITS  OF  THROW-AWAY 
PARTS 
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Investment  Strategy  . =  TECHNOLOGY/RESEARCH  — 

•  TECHNOLOGY  IS  NOT  A  SHOW  STOPPER 

•  SYSTEMS  ENGINEERING  IS  ABSOLUTELY  ESSENTIAL 


•  ENABLING  TECHNOLOGIES  FOR  THE  NEXT 
GENERATION  OF  SEW  SYSTEMS: 

-  Networking  and  Network  Management 

-  Distributed  Fusion 

-  Signature  and  Emission  Control 

-  Distributed  Operating  Systems 


•  SEPARATE  R&D  BRIEF  TO  BE  PRESENTED 
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Investment  Strategy  ■■■■  INSTITUTIONAL  FINDINGS 

•  INSTITUTIONALIZE  COPERNICUS  GOAL 
ARCHITECTURE 

-  EXPAND  TO  INCLUDE  ALL  OF  SEW 

-  CONTINUE  TO  SUPPORT  COPERNICUS  AND  SEW 
BASELINE  PROJECTS  FOR  SHORT  TERM 

-  MERGE  INTO  SEW /COPERNICUS  TEAM  UNDER  A 
SINGLE  SEW/COPERNICUS  ENGINEER 

-  DUTIES  AND  RESPONSIBILITIES 


—  EXPAND  ARCHITECTURE 

—  SELECT  AND  ENFORCE  STANDARDS 

—  REVIEW  ALL  C4I  PROGRAMS  FOR  CONFORM ANCE  TO 
COPERNICUS  AS  A  NORMAL  PART  OF  ACQUISITION  REVIEW 
PROCESS 

—  FOSTER  COTS/COTS 

—  NAVY  SPOC  FOR  ARCHITECTURAL  ISSUES  WITH  DOD,  DCA, 
ETAL. 
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—  Investment  Strategy  \ . — SS5  INSTITUTIONAL  FINDINGS,  SZ 

CONT'D 


•  ACQUISITION  PROCESS 

-  "TRAIL  BOSS"  ANALOG  FOR  SEW 

-  INSTITUTIONALIZE  EVOLUTIONARY 
DEVELOPMENT  WITHIN  THE  ACQUISITION 
PROCESS 

-  REVISE  DOD/JOINT/SECNAV  DIRECTIVES 

-  REQUIRE  SEW/COPERNICUSENGINEER  APPROVAL 
FOR  ALL  SEW  PROGRAMS 
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OUTLINE 


•  EXAMINATION  OF  REQUIREMENTS  (PHASE  I  OF  II) 

-  TOP  DOWN,  BOTTOM  UP 

-  ARCHITECTURE  ASHORE  AND  AFLOAT 

-  IDENTIFICATION  OF  HIGH  PRIORITY  PROGRAMS 

•  MANPOWER,  PERSONNEL,  AND  TRAINING 

•  TECHNOLOGY  AND  R&D  FINDINGS  (SEPARATE 
BRIEF) 

•  INSTITUTIONAL  ISSUES  AND  REQUIREMENTS 

•  CONSOLIDATED  PRINCIPAL  RECOMMENDATIONS 
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Investment  Strategy  lllllll,lll,l.lll "  . .  SUMMARY 


•  USE  THE  PILLAR  PRIORITY  REQUIREMENTS  AS  A 
POM-94  STARTING  POINT. 

•  TECHNOLOGY  IS  NOT  A  SHOW  STOPPER 

•  CHARTER  SEW/COPERNICUS  SYSTEM  ENGINEER 

•  ESTABLISH  AND  ENFORCE  ARCHITECTURE 
STANDARDS 

•  FOSTER  STREAMLINING  OF  THE  ACQUISITION 
PROCESS  (THROUGH  TRAIL  BOSS,  SYSTEMS 
ORIENTATION,  ETC.) 

•  MPT  MUST  BE  THE  CORNERSTONE  FOR  THE 
SEW/COPERNICUS  INVESTMENT  STRATEGY 
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The  Copernicus  Architecture 

Investment  Strategy 
R&D  Panel 
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S  Investment  Strategy 


DEFINING  TERMS 


RfcP  Categories 

•  Research  (6.1)  -  ONR 

•  Explortoiy  Development  (62)  -  ONT 

•  Advanced  Development  (6JA)  -  OAT  + 


•  Advanced  Development  (6JB) 

•  Engineering  Development  (64)  *0M 


Technology 

•  Functional  Areas  Covering  All  RAD  Categories 


Architecture 

•  Broad  Definition  -  A  Structural  Description  of  a  System  or  Activity 

•  More  Specific  Definition  -  The  Physical,  functional,  and  Organizational 
Arrangement  of  a  Given  Set  of  Related  Entities  for  a  Given  Composition  of 
Forces 

System  Engineering 

•  The  Process  Needed  to  Define  Architectures 

-  Small  Universe  -  Requirements  Driven  Design 
•  Large  Universe  -  Standards  and  Interoperability  Driven  Design 
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=  Investment  Strategy  l  DEFINING  TERMS 

C4I  Architecture 

The  Physical,  Functional,  and  Organizational  Arrangement  of  C4I 
for  a  Given  Composition  of  Forces 

•  Physically  -  Hardware/Software  Elements  (What  the  Elements  are) 

•  Functionally  -  What  the  Elements  Do 

•  Organizationally  -  Chain  of  Command,  Structure  and  Responsibility 

•  Compositionally  -  What  Set  of  Forces /Platforms  are  Being  Considered 

Copernicus  Architecture 

The  Physical,  Functional,  and  Organizational  Arrangement  of  C4I 

•  Physically  -  Specifies  and  Defines  the  Consistent  Set  of  Rules  for  the 
Development  and  Combining  of  Hardware/Software  (NFC,  JOINT, 
COMBINED) 

•  Compositionally  -  Open  Architecture,  within  Bounds 

•  Achievable  within  the  State-of-the-Art 

Copernicus  Goal  Architecture 

•  The  Implemented  Copernicus  Architecture 
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Top  Down 

Investment  Strategy  SSS . . g  GAME  PLAN  FOR 

COPERNICUS  R&D 


Copernicus 

Building 

Blocks 


Tech 

Team 


Comma 

Team 
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- =  TECHNOLOGY  CONCLUSIONS  = 


What's  Important  ’Now 

•  Copernicus  Architecture  Needs  System  Engineering  and  Expansion  to  the  Total 
SEW  Architecture 

•  Engineering  Development  Needs  to  Concentrate  on: 

-  Fixing  Critical  SEW  Deficiencies 

-  Applying  Technologies  to  the  Copernicus  Communications  Backbone 

-  Transitioning  Enduring  Systems  to  New  Goal  Architecture 
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=  Investment  Strategy  Z .  MANAGEMENT  CONCLUSIONS  = 


•  Work  Gosely  with  ONT  on  Expl  Dev  investments,  Establish  Transition  plans 
for  SEW  Efforts 

•  Promote  the  Changing  of  Acquisition  Rules  to  Accomodate  rapidly  Changing 
Technology 

-  Work  with  OP-91  to  Change  OPNAVINSTRs 

-  Work  with  ASN  to  Change  SECNAVINSTs 

-  Promote  Evolutionary  Acquisition  in  all  Instructions 
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m 

=  InvestmentStrategy  =  IMPLEMENTA  TION  CONCLUSIONS  = 


Copernicus  Architectural  Details  Need  To  Be  Specified 

And  Expanded  So  That  R&D  Deficiencies  Can  Be  Fully  Addressed 

•  Establish  dedicated  OPNAV/SYSCOM  team  supported  by  Navy  labs 

•  POA&Ms  required 

SEW  Concept  Needs  To  Be  Defined 

•  Establish  a  team  to  develop  ’The  SEW  Concept" 

-  Top  down  integrated  sense 

-  Near  and  far  term  objectives  and  implications 

-  Address  both  warfare  mission  area  (investment  strategy)  and  SEWC 
(CWC)  aspects 
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TOP  DOWN  R&D  COPERNICUS 
BUILDING  BLOCKS 


Navy  R&D  "Roadmap" 

Copernicus  Building 
Blocks 

Examples  of 

R&D  Focal  Points 

Commercial  Utilization 

DOD  Government 
Utilization 

Navy  R&D  Investments 
(Recommended) 

Correlation  Algorithms 

NTCS-A,  SGS/AC,  OSS, 

iuss,  csesEtAAcn, 

F-14,  P-3C,  A*gia,  ASWOC,  «tc. 

Use  civil  and  commercial 
products 

Use  Air  Force,  SDI,  Army 
algorithms.  High  availability, 
must  make  correct  choce 

Low  (6.1) 

High  (6.2,  6.3) 

Med  (6.4) 

Copernicus  Common 
Tactical  Software 

NTCS-A,  AUTO  ID, 

OSS,  CS@SE(CSDS), 

IUSS 

Use,  e.g..  Data  Base,  Spreadsheet, 
Office  Automation  programs 

Don’t  pursue  due  to  low 
availability 

Need  DBMS  development 

High  (63, 6.4) 

Network  /  Systems 
Management 

NTCS-A,  OSS 

Leverage  Standards  (e.g.,  SNMP) 

Use  Commercial  standards,  not 
local  inventions. 

High  (6.2,  6.3) 

Workstation  Engines 

NTCS-A,  AUTO  ID,  OSS, 
TDA,  NGCR,  NIPS, 
CS@SE 

Leverage  Standards,  use 
ruggedized  systems  where 
applicable 

Settle  on  Navy  Requirements 
and  leverage  commercial. 

High,  to  transition  systems  and 
packaging  of  commercial 
technology 

Network  Services 

DCS,  DDN,  DTCN, 
FTS-2000 

Leverage  Standards 

Strongly  pursue  due  to  high 
availability 

Program  Specific  High,  to 
integrate  current  enduring 
systems. 

INFOSEC 

System  by  System 

Use  industrial  security 
products  as  applicable 

NSA,  High  Availability 
(UNIGUARD  COTS,  TC/IP) 

Med  (63) 

Common  Decision 
Support  Software 

NTCS-A,  OSS,  IUSS, 
ASWOC,  TAMPS,  TDA 

Leverage  MMI  Standards 
(e.g.,  MOTIF) 

Don’t  pursue  due  to  low 
availability 

Med  (63, 63) 

Data  File  Servers 

OSS 

Leverage  Standards  (e.g.,  NFS) 

Settle  on  Navy  Requirements 
and  leverage  commercial. 

Med  to  integrate  existing 
enduring  systems. 

Desktop  Engines 

SNAP,  NST  Ashore 

Leverage  Standards 

Settle  on  Navy  Requirements 
and  leverage  commercial. 

Develop  as  Part  of  Programs 

Comm  Servers 

NAVCOMPSRS/LDMX* 

NAVMACS/CUDDCS* 

NTCS-A,  Integrated  SI  Comm** 
Long  Haul  Comm**,  DOS 

Leverage  Standards 

Settle  on  Navy  Requirements 
and  leverage  commercial. 

Develop  as  Part  of  Programs 

Sensor  Specific 
Application 

System  by  System 

Don’t  pursue,  no  utilization 
expected 

Don’t  pursue  due  to  low 
availability 

Develop  as  Part  of  Programs 

Data  Compression 

TRAP 

Leverage  Standards 

Strongly  pursue  due  to 
high  availability 

Low  (6.1, 63) 

Data  Robots 

None  Known 

Leverage  Standards  (e.g.,  SQL) 

Don’t  pursue  due  to  low 
availability 

Low  (6.2) 

Environmental  Analysis 

PMW  161  Programs, 
TESS-3,  TAMPS,  ASWOC, 
etc. 

Don’t  pursue,  no  utilization 
expected 

Strongly  pursue  due  to 
high  availability 

Low  (6.1, 63) 

Med  (63) 

Tran- Sanitization 
Software 

TENCAP 

Don’t  pursue,  no  utilization 
expected 

Pursue  with  NSA, 
low  availability 

Low  (6.3) 

Display  Devices 

OSS,  NTCS-A, 

Aegis  ADS 

Leverage 

Standards 

Settle  on  Navy  Requirements 
and  leverage  commercial 

Low  (6.2,  63)  For  rugged 
packaging  of  commercial 
technology 

Modular  Embedded 
Crypto 

Classic  Lightning 

Don't  pursue,  no  utilization 
expected 

Pursue  with  NSA, 
low  availability 

Low  (6.2,  63) 

STU-m 

Don’t  pursue,  no  utilization 
expected 

Influence  OSD  to  support 
MANTECH  to  reduce  costs 

Low  (6.4) 

In  ter  chan  gable  Modems 

None  Known 

Leverage  Standards 

Settle  on  Navy  Requirements 
and  leverage  commercial 

None.  Use  as  approprite. 

Not  an  R&D  issue. 

Standard  Storage 

Devices 

None  Known 

Leverage  Standards 

Strongly  pursue  due  to 
high  availability 

None.  Use  as  approprite. 

Not  an  R&D  issue. 
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Abbreviations/Acronvms 

AAW 

And- Air  Warfare 

AAWC 

Anti- Air  Warfare  Commander 

ABN 

Airborne 

ACDS 

Advanced  Combat  Direction  System 

ACP 

Allied  Communications  Publications 

ACS 

Afloat  Correlation  System 

ADP 

Automated  Data  Processing 

AIC 

Atlantic  Intelligence  Center 

AJ 

Anti-jam 

AMW 

Amphibious  Warfare 

ANCC 

Automated  Network  Control  Center 

ANDVT 

Advanced  Narrowband  Digital  Voice  Terminal 

AOR 

Area  of  Responsibility 

AREC 

Air  Resources  Element  Coordinator 

ASUW 

Anti-surface  Warfare 

ASUWC 

Anti-surface  Warfare  Commander 

ASW 

Anti-submarine  Warfare 

ASWC 

Anti-submarine  Warfare  Commander 

ASWIXS 

ASW  Information  Exchange  System 

ASWM 

ASW  Module 

ASWOC 

ASW  Operations  Center 

ATF 

Amphibious  Task  Force 

ATP 

Advanced  Tactical  Protype 

AUTODIN 

Automatic  Digital  Network 

AWACS 

Airborne  Warning  and  Control  System 

BDA 

Battle  Damage  Assessment 

BF 

Battle  Force 

BG 

Battle  Group 

BGPHES 

Battle  Group  Passive  Horizon  Extension  System 

BITS 

Base  Information  Transfer  System 

BLOS 

Beyond  Line-of-Sight 

BOM 

Bit  Oriented  Message 

C&D 

Command  and  Decision 

C&P 

Characteristics  and  Performance 

C3CM 

Command,  Control,  Communications  Countermeasures 

C4 

Command,  Control,  Communications  and  Computers 

C*I 

Command,  Control,  Communications,  Computers  and  Intelligence 

C*IC  M 

0*1  Countermeasures 

c*s 

Command,  Control,  Communications,  and  Computer  Systems 

CAL 

Computer  Aided  Logistics 

CALOW 

Contingency  and  Limited  Objective  Warfare 

CAS 

Close  Air  Support 

G-2  •  Glossary 


CATF 

Commander,  Amphibious  Task  Force 

CCC 

CINC  Command  Center 

CDBS 

Central  Data  Base  Server 

CDC 

Combat  Direction  Center 

CDS 

Combat  Direction  System 

CIA 

Central  Intelligence  Agency 

CIC 

Combat  Information  Center 

CIM 

Corporate  Information  Management 

CINC 

Commander  in  Chief 

CINCLANTFLT 

Commander  in  Chief  U.S.  Atlantic  Fleet 

CINCPAC 

Commander  in  Chief  U.S.  Pacific  Command 

CINCPACFLT 

Commander  in  Chief  Pacific  Fleet 

CINCUSNAVEUR 

Commander  in  Chief  U.  S.  Navy  Europe 

CLF 

Commander  Landing  Force 

CLNP 

Connectionless  Network  Protocol 

CMSA 

Cruise  Missile  Support  Activity 

CNO 

Chief  of  Naval  Operations 

COE 

Common  Operating  Environment 

COM 

Character  Oriented  Message 

COMNA  V  SECGRU 

Commander  Naval  Security  Group 

COMNAV  SP  ACECOM 

Commander  Naval  Space  Command 

COMOPTEVFOR 

Commander,  Operational  Test  and  Evaluation  Force 

COMPUSEC 

Computer  Security 

COMSEC 

Communications  Security 

COMSPAWARSYSCOM 

Commander,  Space  and  Naval  Warfare  Systems  Command 

CONOP 

Concept  of  Operations 

CONUS 

Continental  United  States 

COOP 

Continuity  of  Operations  Planning 

COPCOM 

Copernicus  Common 

COSL/P 

Commander  Oceanographic  Systems,  Atlantic/Pacific 

COTS 

Commercial  Off-the-Shelf 

CPA 

Closest  Point  of  Approach 

CPE 

Consumer  Premise  Equipment 

CSG 

Cryptologic  Support  Group 

CSRF 

Common  Source  Routing  File 

CSS 

Communication  Support  Service 

CTO 

Communication  Technician  Operator 

CUDIXS 

Common  User  Data  Information  Exchange  System 

CV 

Carrier 

CVBG 

Carrier  Battle  Group 

CVIC 

Carrier  Intelligence  Center 

CWC 

Composite  Warfare  Commander 

G-3  •  Glossary 


Abbreviations/Acronvms 

DAMA 

Demand  Assigned  Multiple  Access 

DCA 

Defense  Communications  Agency 

DCS 

Defense  Communication  System 

DCTN 

Defense  Commercial  Telecommunications  Network 

DDN 

Defense  Data  Network 

DECCO 

Defense  Commercial  Contracting  Office 

DF 

Direction  Finding 

DIA 

Defense  Intelligence  Agency 

DISN 

Defense  Information  Systems  Network 

DISNET 

Defense  Integrated  Secure  Network 

DMS 

Defense  Message  System 

DOD 

Department  of  Defense 

DP 

Data  Processing 

DSCS 

Defense  Satellite  Communications  System 

DSSCS 

Defense  Special  Security  Communications  System 

DTC-2 

Desktop  Computer  2 

EC 

Electronic  Combat 

ECCM 

Electronic  Counter-countermeasure 

ECM 

Electronic  Countermeasure 

EDI 

Electronic  Data  Intelligence 

EHF 

Extremely  High  Frequency 

ELINT 

Electronic  Intelligence 

ESM 

Electronic  Support  Measures 

EW 

Electronic  Warfare 

EWC 

Electronic  Warfare  Coordinator 

EWCM 

Electronic  Warfare  Coordination  Module 

FASTT 

Fleet  All-Source  Tactical  Terminal 

FCC 

Fleet  Command  Center 

FDD 

Functional  Description  Document 

FDDI 

Fiber  Distributed  Data  Interface 

FDM 

Frequency  Division  Multiplex 

FEP 

Fleet  Satellite  Communications  Extremely  High  Frequency  Package 

fic 

Fleet  Intelligence  Center 

FIPS 

Federal  Information  Processing  Standards 

fist 

Fleet  Imagery  Support  Terminal 

FLTCINC 

Fleet  Commander  in  Chief 

FLTSATCOM 

Fleet  Satellite  Communications 

FMP 

Fleet  Modernization  Program 

FNOC 

Fleet  Numerical  Oceanographic  Center 

FOSIC 

Fleet  Ocean  Surveillance  Information  Center 

FOSIF 

Fleet  Ocean  Surveillance  Information  Facility 

FOTC 

Force  Over-the-Horizon  Track  Coordinator 
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FOT&E 

Follow-On  Test  and  Evaluation 

FPT 

Fleet  Project  Team 

FRWG 

Fleet  Requirements  Working  Group 

FSC 

File  Server  Control 

FT  AM 

File  Transfer,  Access,  and  Management 

FTC 

Force  Track  Coordinator 

FTD 

Foreign  Technology  Directorate 

FTS2000 

Federal  Telephone  System  2000 

GENSER 

General  Service 

GLOBIXS 

Global  Information  Exchange  System 

GOSIP 

Government  Open  Systems  Interconnection  Profile 

GOTS 

Government  Off-the  Shelf 

GSA 

General  Services  Administration 

HARDMAN 

Hardware/Manpower 

HDTV 

High  Definition  Television 

HF 

High  Frequency  * 

HFMR 

HF  Modem  Replacement 

HIT 

High  Interest  Track 

HMI 

Human  Machine  Interface 

HSFB 

High  Speed  Fleet  Broadcast 

I&W 

Indications  and  Warning 

ICA 

Integrated  Communications  Architecture 

IEEE 

Institute  for  Electrical  and  Electronic  Engineers 

ILS 

Integrated  Logistic  Support 

INSICOM 

Integrated  Special  Intelligence  Communications  Architecture 

INTELCAST 

Intelligence  Broadcast 

INTELNET 

Intelligence  Network 

IOC 

Initial  Operational  Capability 

IS -IS 

Intermediate  System  -  to  -  Intermediate  System 

ISDN 

Integrated  Services  Digital  Network 

ITDN 

Integrated  Tactical-Stategic  Data  Network 

IUSS 

Integrated  Undersea  Surveillance  System 

JANAP 

Joint  Army  Navy  Air  Force  Publication 

JCS 

Joint  Chiefs  of  Staff 

JIC 

Joint  Intelligence  Center 

JINTCCS 

Joint  Interoperability  Tactical  Command  and  Control  Systems 

JOPES 

Joint  Operations  Planning  and  Execution  System 

JOTS 

Joint  Operational  Tactical  System 

JTF 

Joint  Task  Force 

JTIDS 

Joint  Tactical  Information  Distribution  System 

JVIDS 

Joint  Visually  Integrated  Display  System 

LAMPS 

Light  Air  Multi-Purpose  System 
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LAN 

Local  Area  Network 

LEC 

LAMPS  Element  Coordinator 

LEIP 

Link  Eleven  Improvement  Program 

LF 

Low  Frequency 

LOS 

Line  of  Sight 

LPI 

Low  Probability  of  Intercept 

M^2 

Multi  Media  Communication  Control 

MAGTF 

Marine  Air  Ground  Task  Force 

MAN 

Metropolitan  Area  Network 

MDR 

Medium  Data  Rate 

MEB 

MEV 

MEC 

Main  Evaluation  Center 

MHS 

Message  Handling  System 

MIDS 

Multifunctional  Information  Distribution  System 

MILSATCOM 

Military  Satellite  Communications 

MLS 

Multilevel  Security 

MPA 

Marine  Patrol  Aircraft 

MPN 

Manpower  Personnel,  Navy 

MPT 

Manpower  and  Training 

MTBF 

Mean  Time  Between  Failure 

MTBO 

Mean  Time  Before  Obsolescence 

NATO 

North  Atlantic  Treaty  Organization 

NAVCOMMSTA 

Naval  Communications  Station 

NAVIXS 

Navy  Information  Transfer  System 

NAVNET 

Navy  Network 

NAVSTAR  GPS 

Navigation  Satellite  Timing  and  Ranging  Global  Positioning  System 

NAVSTKWARCEN 

Naval  Strike  Warfare  Center 

NCA 

National  Command  Authorities 

NCCS 

Navy  Command  and  Control  System 

NCO 

Net  Control  Outstation 

NCSO 

Naval  Control  of  Shipping  Organizations 

NCTAMS 

Naval  Computer  and  Telecommunications  Area  Master  Station 

NCTC 

Naval  Computer  and  Telecommunications  Command 

NDI 

Non-developmental  Item 

NEC 

Navy  Enlisted  Codes 

NESP 

Navy  EHF  Satellite  Program 

NFC 

Numbered  Fleet  Commander 

NGFS 

Naval  Gun  Fire  Support 

NOIC 

Naval  Ocean  Intelligence  Center 

NIPS 

Naval  Intelligence  Processing  System 

NMC 

Network  Management  Centers 
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NMCS 

National  Military  Command  System 

NOPF 

National  Oceanographic  Processing  Facility 

NSA 

National  Security  Agency 

NSOC 

National  Signals  Intelligence  Operations  Center 

NST 

Navy  Standard  Teleprinter 

NSWC 

Naval  Surface  Weapons  Center 

NTCC 

Naval  Telecommunications  Center 

NTCS-A 

Naval  Tactical  Command  System  Afloat 

NTIC 

Naval  Technical  Intelligence  Center 

NWOC 

Navy  Weather  and  Oceanographic  Center 

NWP 

Naval  Warfare  Publication 

NWTDB 

Naval  Warfare  Tactical  Data  Base 

OBU 

Ocean  Surveillance  Information  System  Baseline  Upgrade 

OCR 

Optical  Character  Reader 

ODA/ODDF 

Office  Document  Architecture/Office  Document  Interchange  Format 

OED 

OSIS  Evolutionary  Development 

OJT 

On-the-Job  Training 

OM&N 

Operations  and  Maintenance,  Navy 

ONT 

Office  of  Naval  Technology 

OPDEC 

Operational  Deception 

OPINTEL 

Operational  Intelligence 

OPLANS 

Operation  Plans 

OPN 

Other  Procurement,  Navy 

OPNAV 

Office  of  the  Chief  of  Naval  Operations 

OPSEC 

Operational  Security 

OPTEVFOR 

See  COMOPTEVFOR 

OR 

Operational  Requirement 

OS/IPC 

Operating  System/Inter-process  Communications 

OSI 

Open  Systems  Interconnection 

OSIS 

Ocean  Surveillance  Information  System 

OSP 

Ocean  Surveillance  Product 

OSS 

Operations  Support  System 

OTC 

Officer  in  Tactical  Command 

OTCixsn 

Office  in  Tactical  Command  Information  Exchange  System  Phase  n 

OTCIXS 

Officer  in  Tactical  Command  Information  Exchange  System 

OTH 

Over-the-Horizon 

OTH-T 

Over-the-Horizon  Targeting 

1*1 

Pre-planned  Product  Improvement 

PAT 

Process  Action  Team 

PC  AD 

Program  Change  Approval  Document 

PIM 

Planned  Incremental  Modernization 

PLRS 

Position  Location  Reporting  System 
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PMO 

Project  Management  Office 

POA&M 

Plan  of  Action  and  Milestones 

POM 

Program  Objective  Memorandum 

POST 

Prototype  Ocean  Surveillance  Terminal 

QA 

Quality  Assurance 

QMB 

Quality  Management  Board 

R&D 

Research  and  Development 

RACC 

Regional  ASW  Command  Centers 

RDIXS 

Research  and  Development  Information  Exchange  System 

RDT&E 

Research,  Development,  Test,  and  Evaluation 

RF 

Radio  Frequency 

RFC 

Request  for  Comment 

RFI/EMI 

Radio  Frequency  Interference/Electromagnetic  Interference 

RM 

Radioman 

RRC 

Regional  Reporting  Centers 

SACC 

Shore  ASW  Command  Center 

SACEUR 

Supreme  Allied  Commander  Europe 

SACLANT 

Supreme  Allied  Commander  Atlantic 

SAG 

Surface  Action  Group 

SAR 

Search  and  Rescue 

SATCOM 

Satellite  Communications 

SCE 

Standard  Communication  Environment 

SCI 

Sensitive  Compartmented  Information 

SDLS 

Satellite  Data  Link  Standard 

SDS 

Surveillance  Direction  System 

SEW 

Space  and  Electronic  Warfare 

SEWC 

Space  and  Electronic  Warfare  Commander 

SHF 

Super  High  Frequency 

SI 

Special  Intelligence 

SIC 

Subscriber  Interface  Control 

SIGINT 

Signal  Intelligence 

SIGSEC 

Signal  Security 

SINCGARS 

Single  Channel  Ground  and  Air  Radio  System 

SMTP 

Simple  Mail  Transfer  Protocol 

SOC 

Sector  Operations  Center 

SOCC 

Submarine  Operations  Command  Center 

SOE 

Standard  Option  Equipment 

SOF 

Special  Operations  Forces 

SOSUS 

Sound  Surveillance  System 

SSA 

Software  Support  Activity 

SSC 

System/Site  Control 

SSES 

Ship  Signals  Exploitation  Space 

G-8  •  Glossary 

Abbreviations/Acronvms 

SSGN 

Guided  Missile  Submerine,  Nuclear 

SSIC 

Standard  Subject  Identification  Code 

SSIXS 

Submarine  Satellite  Information  Exchange  System 

STU-m 

Secure  Telephone  Unit  m 

STW 

Strike  Warfare 

STWC 

Strike  Warfare  Commander 

SUBOPAUTH 

Submarine  Operating  Authority 

SUPPLOT 

Supporting  Plot 

SURTASS 

Surface  Towed  Array  Surveillance  System 

SVS 

Secure  Voice  System 

SYDP 

Six  Year  Defense  Plan 

SYSCOM 

System  Command 

TACAIR 

Tactical  Air 

TACMEMO 

Tactical  Memo 

TACREP 

Tactical  Report 

TACTASS 

Tactical  Towed  Array  Surveillance  System 

TAD 

Temporary  Assigned  Duty 

TADKS 

Tactical  Data  Information  Exchange  System 

TAMPS 

Tactical  Air  Mission  Planning  System 

TARPS 

Tactical  Airborne  Reconnaissance  Pod  System 

TASS 

Towed  Array  Surveillance  System 

TCC 

Tactical  Command  Center 

TDA 

Tactical  Decision  Aids 

TDBM 

Tactical  Data  Base  Manager 

TDP 

Tactical  Data  Processor 

TEAMS 

Tactical  EA-6  Mission  Planning  System 

TENCAP 

Tactical  Exploitation  of  National  Capabilities 

TERPS 

Tactical  Electronic  Reconnaissance  Processing  and  Evaluation  System 

TFCC 

Tactical  Flag  Command  Center 

TIMS 

TFCC  Information  Management  System 

TP 

Transaction  Processing 

TP2 

Transport  Protocol  Class  2 

TQL 

Total  Quality  Leadership 

TRE 

Tactical  Receive  Equipment 

TIE 

Technical  Training  Equipment 

TTY 

Teletype 

UFO 

UHF  Follow  On 

UHF 

Ultra  High  Frequency 

USA/USAF 

U.  S.  Army/U.S.  Air  Force 

USCINC 

U.  S.  Commander  in  Chief 

USCINCPAC 

Commander  in  Chief  U.S.  Pacific  Command 

USMC 

United  States  Marine  Corps 
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USMTF 

VHF 

VT 

WAM 

WIN 

WMA 

WWMCCS 


U.S.  Message  Text  Format 
Very  High  Frequency 
Virtual  Terminal 
WWMCCS  ADP  Modernization 
WWMCCS  Intercomputer  Network 
Warfare  Mission  Area 

Worldwide  Military  Command  and  Control  System 


